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This  document  is  meant  tc  be  usea  as  a  "reference"  manual  by 
CLFARS  programmers  or  people  who  are  tc  maintain  an  existing 
"portable"  CLPARS  system.  Most  of  the  overview  information  shculc 
be  gotten  from  the  CL PARS  V  Final  Report. 

This  manual  contains  information  only  about  the  •'  ling 
structure,  I/C  packages  and  F.SX-1  IK  specific  features  of  "tc:  hie" 
CLFARS.  Cetailea  information  about  specific  CLFAhS  programs  ula 
be  obtained  from  the  CLPARS  V  and/cr  CL PARE  VI  Software  Re.  oe 
Manuals . 

Within  these  pages  you  will  find  information  about  the 
structure  of  all  the  CLPARS  files  and  how  tc  access  the  content  of 
these  files.  A  separate  section  describes  the  different  "cisplays" 
CLPARS  generates,  along  with  detailed  information  about  the 
contents  of  a  user’s  "display"  files.  Terminal  and  text-file  input 
ana  output  packages  are  discussed  in  detail  here,  also. 

The  basic  ideas  behind  this  current  design  of  CLPARS  are  the 
maximum  utilization  of  a  standardized  programming  language  (FCRTRAi. 
IV)  for  algorithm  processing  and  the  abstract  treatment  cf  the  data 
by  programs  through  the  filing  system  and  ir.put/cutput  processes. 
That  is,  all  CLFARS  processing  routines  will  utilize  subroutines 
for  accessing  data  files  and  performing  ir.put/cutput. 


O'cr.secuer.tl  ,  these  processing,  rot. tines  can  be  machine  arc  system 
ir.ct.fcr.utnt  ar.c  car.  te  transferred  tc  any  computer  ccnf  i/jurt-ticr. 
having  a  F C A  7  NAN  IV  compiler .  Cr.  each  implementation,  cr. iy  a 
1  itr  i  ted  number  of  subroutines,  v.kich  are  machine  cr  system 
dependent,  will  have  tc  be  reprcgrarr.rr.ee.  Thus ,  the  key  feature  cf 
this  cesigr.  is  the  concept  cl'  "portability". 


1.C  LLc  IG!>  OVERVIEW 

In  this  section,  we  present  a  brief  cverviev.  of  the  cesigr,  fer 
the  "portable"  CLPARS;  ether  sections  will  discuss  ir.aiv  id  tally , 
in  greater  cepth,  the  key  features  cf  the  design. 

As  mentioned  in  the  Ir.trcduc ticn ,  an  important  cesigr. 
ingredient  in  designing  a  machine  and  terminal  independent,  cr 
"portable",  CLFARS  is  the  maximum  utilization  cf  FORTRAN  as  a 
star.darc,  high  level  language  which  can  be  compiled  cr,  ar.y  machine 
cn  which  CLPARS  is  likely  to  be  implemented.  Ibis  feature,  the  use 
cf  FORTRAN,  is  almost  a  design  "must"  in  reaching  the  machine 
independent  goal.  however,  since  different  computers  have 
different  operating  systems  (seme  computer  installations  may 
utilize  mere  than  one  operating  system,  with  the  same  computer),  anc 
since  operator  terminals  and  other  per ipherals  are  not  stsr.carc, 
inaepender.ee  within  the  filing  system  and  I/C  mechanism  is 


difficult  tc  achieve. 


which 


cr.  t 
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There  icrt- ,  ir.  CLPAi.S,  which  is  heavily  file  orient.ec. 
highly  ce;er.Ger;t  cr.  graphic  I/C  ar.d  c^erttcr  interaction,  t:.e  use 
ci  iChlhAt.  only  partially  rr.ee  ts  the  goal  of  portability.  "r.e  ether 
Key  aspects  c:  the  portable  CLPAi.S  cesigr.  are :  the  separate 
prcrrair.  apprcacr.  witn  a  ccn.mand  input  processor  (CIP);  the  use  of 
files  for  passing  parameters  and  cats;  and  ar.  ir.put/cutput  package 
for  performing  I/C.  Each  of  these  areas  will  be  ciscussec 
separately  ir.  subsequent  sections. 


1.1  II. E  CCMi-.AKL  I'.'Ft’T  PECCESSCE  (CIF) 

From  system  tc  system,  programs  are  initiatec  (startec  up) 
differently.  The  CIP  is  designed  tc  overcome  these  differences. 
Each  CLFARS  function  is  designee  as  a  separate  program  ar.c  should 
in  itself  be  portable.  In  order  tc  make  the  initiation  cf  each 
program  uniform,  there  is  a  system-ceper.dent  module,  the  CIF,  which 
acts  as  an  interface  between  CLFARS  ar.c  the  user.  This 
mini-executive  accepts  the  CLPARS  program  name  ar.c  performs  any 
system  required  operations  needed  to  cause  that  program  tc  run. 

The  CIP,  along  with  the  separate  program  approach,  will 
support  portability,  modularity,  ease  cf  maintenance  ar.c  expansion, 
and  promote  structural  freedom  in  command  execution.  The  CIF  is 
discussed  in  detail  in  Section  2  and  the  design  for  the  CIF  under 
ESX-11K  v3-2  can  be  found  in  Appendix  A  cf  this  manual. 


r 

Ir. t  rccuc  t  i cr.  —  1 
«L' PILLS  At.L  1 !.  P  L I  /  C  LTF  LI 

1.1  ,.LS  I  I.  ACT  FULL  ALL  1 1. 1  LT/C  IT  l  LT 

Ir:  crcer  tc  cccciuixci-le  various  filing  sy i;er:s,  wore  sizes  tr.c 
I/w  peculiarities  into  the  design  cf  the  portable  CLFARS,  etch  cl 
the  ir.civicual  programs  which  i:,. pieir.er.t  a  function  will  treat  file 
data  ar.c  I/t  abstractly,  lhat  is,  the  pregrams  will  "knew"  what 
aata  is  ir.  a  file,  ar.c  will  call  a  subroutine  tc  store  cr  retrieve 
the  data.  The  subroutine,  cr  possibly  levels  cf  subroutines, 
"knew"  the  tcrrr.at  cf  the  files  and  hew  tc  access  the  physical  cata 
reccrcs. 

I/C,  particularly  graphic  I/C,  will  also  be  abstractec  by 
subroutine  calls.  Thus,  the  individual  programs  which  perform  the 
CLFARS  commands  will  be  completely  system  independent;  only  the 
sutreutines,  which  translate  the  abstract  requests  into  specific 
ccce  for  a  particular  system,  will  be  system  or  terminal  dependent. 

1.3  C  CM!':  A  ML  STRLCTLRE 

The  command  structure  (see  CLPAF.S  V  Final  Report)  for  portable 
CLFARS  has  been  kept  similar  to  that  cf  the  Kultics  CLPARS 
Cperating  System  (MCCS).  The  complete  structural  freedom  of  MCCS 
has  been  retained.  Complete  designs  for  the  programs  that  will 
carry  out  user  commands  and  all  necessary  subroutines  can  be  fcunc 
in  the  CLFARS  V-VI  Program  Specifications.  Detailed  descriptions 
of  all  the  programs  that  have  beer,  written  under  the  CLFARS  VI 


contract  car.  be  found  in  the  CLPARS  VI  Software  Reference  Manual 
(SRM).  The  CLPARS  V  Software  Reference  Manual  contains  program 


r 
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spec  i t  icat icr.s  cf  all  the  programs  initially  cesigr.ec  fer 
"portable"  GLFAKL'.  I.ete ,  the  CLFAF.S-t  I  eh!-,  is  net  a  perlc-ct  subset 
c !'  the  CLPAhG-V  bf.h  . 

1.E  CLFAhG  T F.AI.SFG  hi ATIGI.  CCl.SIE.EnA7;  f.S 

Ideally,  the  best  way  to  transport  CLPAKS  to  a  new  operating 
system  is  to  have  two  knowledgeable  people;  cr.e  who  "knows"  GLrAnb 
ir.sice  out  and  one  who  "knows"  the  host  operating  system 
input/output  (1/C)  facilities  ir.sice  cut.  As  is  usual  when 
transporting  application  software,  the  I/C  sections  must  be 
rewritten  to  accomccate  the  new  operating  system,  ether  system 
deper.cent  ccr.siceratior.s  must  also  be  taken  into  account.  Fcr 
instance,  how  are  cr.aracter  strings  represer.tec  in  the  local 
FCnTRAI.  compiler?  Is  tne  length  of  the-  character  string  ceterr.inec 
by  counting  the  number  of  characters  until  an  enc-cf-str ing  symbol 
is  encountered,  or  is  th ere  a  portion  cf  tr.e  string  reserveu  to 
store  the  length  attribute?  Are  the  strings  directly  accesible  to 
a  program,  or  is  there  an  indirect  reference  tc  the  string  through 
a  string  descriptor?  Does  the  host  operating  system  allow 
"spawning"  or  invocation  of  one  program  through  another  program 
(GLPARS  may  use  spawning  for  a  "clean"  user  interface)?  kill  tr.e 
programs  need  to  be  "overlayed"  and  how  easy  will  it  be  tc  overlay 
the  programs?  (r.cr.trivial  problem  because  reprogramming  cf  entire 
command  structure  may  be  necessary). 


ii 
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In 

"portable" 

CLPARS 

we  have  i 

sclatec  the  L/u 

into  packages. 

Lection 

C  c i  this 

rr^nual 

explains 

in  great  detail 

w.'.at  the  results 

ot  the  terminal  anc  text  file  I/L  package  should  lock  like, 
iecticr.  1  explains  the  abstract  concept  ci  LLFAf-c  "block"  I/L 
package  (FCET,FFLT)  anc  Level  I  routines. 

System  dependent  features  cf  the  portable  CLrAKS  design  are 
pointed  out  in  many  of  the  sections  where  they  occur.  A  summary  of 
the  system  depencent  functions  is  given  in  Lection  £.  The 
appendices  contain  a  discussion  cf  the  designs  of  how  these  system 
dependent  aspects  will  operate  or.  the  PLP-11/7C  under  F.LX-1  IF 
version  3*L.  The  CLPARS  V  Final  Report  (of  November  15,  1579) 
gives  an  overview  of  the  filing  structure  used  with  the  details 
spelled  cut  in  sections  4  and  5  cf  this  manual.  An  appendix  in  the 
CLFARS  VI  Software  Reference  Fanual  contains  a  list  cf  names  cf  all 
the  system  dependent  programs. 
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IKE  EXECUTIVE 


2  .  C  11.1  ECLECTIC!. 


The  goals  of  an  executive  for  the  portable  F'CRTRAI.  version  of 
CL PA  HE  are  to  ease  the  user's  access  to  the  CL PA  HE  routines,  ana  to 
be  simple  enough  to  provide  a  maximum  amount  of  portability.  The 
latter  goal  is  important  since  the  executive  and  any  accompanying 
overlay  structure  will  be  system  dependent.  Ir.  light  of  these 
goals,  we  have  designed  each  user  command  to  be  a  separate  program 
ana  have  written  a  small  executive  program  to  be  an  interface 
between  the  CLPARS  user  and  the  local  "operating"  system. 


2.1  A  CCKKAf.C  If.  PUT  FRCCESSCP.  (CIF) 


To  install  CLPARS  on  most  computer  operating  systems,  a  short 
executive  called  a  Command  Input  Frccesscr,  or  CIP  for  short,  is 
written.  The  CIP,  normally,  is  s  system  ceper.dent  executive 
program  whose  main  jobs  would  be  to  accept  user  commands  and 
parameters,  adc  any  system  jargon  (e.g.,  Rif.',  paths  to  an  CLPARS 
directory),  place  any  necessary  parameters  in  a  file,  an  then  spawn 
(invoke  or  activate)  the  orograms  requeste  :  .  For  F.SX-1U.  v3.2,  the 
spawning  capability  has  been  left  out  cf  the  CIF  because  it  is 
handled  very  nicely  by  the  system  command  file  processor. 
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The  Executive  --  A 
A  LCI-T-.hl.L  IhFIT  FRCCLhDCR  (CIF) 


Ly  usir.fi  £  CIF,  CLFAF.o  "looks"  the  same  on  different  operati r.g 
systems.  The  user  Goes  r.ot  have  to  add  ALT  statements,  cireetcry 
information,  etc.,  to  his/her  command  line.  Details  about  the 
Command  Input  Processor,  under  the  f.SX-1  IK  version  2.2  operating 
system,  car.  be  found  in  Appendix  A  of  this  manual. 
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As  we  have  seen  in  Section  2,  CLPAF.S  is  considered  as  a  set  of 
individual  programs,  each  of  which  performs  a  particul  sr  pattern 
recognition  algorithm  or  an  ancillary  data  manipulation  function 
which  supports  the  user  and/or  CLPARS  as  a  system.  Each  of  these 
programs  corresponds  to  an  CLPARS  "command."  The  CLPARS  user  calls 
for  the  execution  of  these  commands  in  a  sequence  which  (s)he  deems 
most  appropriate  for  reaching  a  solution  of  a  particular  pattern 
recognition  problem.  In  CLPARS,  files  cf  information  play  a  major- 
role  in  the  system  in  several  important  ways:  storing  the  basic 

input  data;  storing  system  information;  storing  decision  logic 
and  logic  evaluation  results;  and  storing  intermediate  information 
results  of  one  command  which  are  usee  as  inputs  to  subsequent 
commands . 

As  a  result  cf  using  the  approach  described  in  this  section, 
it  will  be  possible  for  each  program  called  by  a  user  to  be  truly 
portable.  All  file  handling  will  be  accomplished  by  a  limited 
number  of  subroutines,  end  only  these  will  have  to  be  rewritten 
when  implementation  is  required  cr.  another  mschine/system . 
Furthermore,  when  writing  the  user-callable  programs,  it  will  not 
be  necessary  to  know  the  details  of  the  file  formats  -  the 
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programmer  need  only  kr.ov.  what.  information  is  stored  in  the  files 
ar.c  utilise  a  set  of  machine-independent  subroutines  which  access 
this  information.  besides  simplifying  the  portability  problems, 
this,  of  course,  makes  implementation  of  new  algorithms  an  easier 
t  ask  . 


Additional  benefits  of  this  approach  include  minimizing 
physical  record  reads  and  writes,  and  an  encoding  scheme  for  naming 
files  which  eliminates  the  need  for  a  program  to  do  repetitious 
character  string  manipulation. 

3.1  DEFINITIONS 

The  following  definitions  apply  to  any  CLPAES  user  file. 

The  basic  unit  of  a  file  is  an  "element."  Each  element  in  a 
file  is  sequentially  numbered  starting  with  1  (one).  An  element 
can  store  a  character,  an  integer,  or  a  real  number;  the  format  of 
our  element  is  the  particular  machine’s  floating  point  format. 
This  definition  eliminates  problems  of  varying  word  sizes  on 
different  computers  or  the  method  of  packing  characters.  Seme 
space  will  be  wasted  by  storing  a  single  character  as  a  floating 
point  word,  but  since  the  great  majority  of  information  stored  in 
CLPARS  files  is  in  the  form  of  real  numbers,  the  small  inefficiency 
of  storage  utilization  is  more  than  eff-set  by  the  universality 
which  results. 


1C 
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h  file  has  a  "header  portion"  which  consists  cf  ’  r. '  elements 
(where  '  r.  ’  could  be  zero),  which  contain  inlormatior,  about  the  file 
as  a  whole  -  e  .g  .  ,  the  number  cf  entries  in  the  file,  cr 
dimensionality  cf  feature  vectors  contained  ir.  a  file. 

The  remaining  portion  of  the  file  (following  the  header) 
consists  cf  "logical  entries",  or  "entries"  fcr  short.  Each 
logical  entry  contains  ’ k ’  elements  ( *  k ’  is  the  same  for  each  entry 
of  a  file;  ' k * ,  cf  course,  can  be  different  fcr  different  files). 
Entries  are  numbered  sequentially  starting  at  1,  It  may  be 
necessary  to  limit  the  maximum  number  of  entries  in  a  file  to  the 
largest  positive  integer  of  the  machine’s  integer  word  format. 

Two  types  of  permanent  files  exist  for  an  CLPAHS  user;  these 
types  are  referred  to  as  "fixed"  and  "variable."  Fixed  files  are 
ranacm  access  files  that  must  exist  in  each  user’s  directory  anc 
contain  information  on  the  status  of  that  user's  CLPAF.5  files. 
There  is  s  determined  number  of  fixed  files  with  fixed  (or  known) 
names.  Some  examples  cf  fixed  files  are: 

Ch  Communications  File 

TL  Tree  List  File 

LL  Logic  List  tile 

LI  Display  Information  File 

Variable  files  are  also  random  access.  The  number  anc  names 
of  variable  files  in  existence  for  a  user  is  variable  (cr  unknown). 
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Examples  cf  variable  files  might  be: 


TI  +  TREEA 
IV  +  TREEA 
TI  +  TREEXYZ 
TV  +  TREEXYZ 
LI  +  FIRSTTRY 


Tree  Information  file  for  Lata  TREEA 
Tree  Vector  file  for  data  I  REE A 
Tree  Information  file  for  data  TREEXYZ 
Tree  Vector  file  for  data  TREEXYZ 
Logic  information  file  for  a  logic 
called  FIRSTTRY 


The  plus  symbol  (+)  denotes  a  sense  of  concatenation.  This  is 
necessary  to  allow  for  the  many  data  trees  and  logics  that  a  user 
may  have  in  his/her  cirectory. 

Temporary  random  access  files  can  be  created  by  the  CLPARS 
application  programs  for  specific  purposes.  In  addition, 


sequential  files  are  used  in  the  process  of  creating  printer  output 
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1.2  FILL  EYSTLF  I.  CUT  IKES  ALL  IS  ACE 

There  is  a  basic  set  of  system  dependent  file  manipulation  anu 
accessing  routines  within  CL FARE.  The  manipulation  routines  are 
called  CC  PEI. ,  CCKEAT(E),  CCLCSE,  CLELET  (  E  )  ,  CRELAF  (  E  )  ,  and  CECIL. 
These  routines  perform  the  following  functions: 

CCFEI.  Cpen  an  existing  "system"  file 

CChEAT  Create  and  open  a  new  "system"  file 

CCLCSE  Close  an  opened  "system"  file 

CCELET  Delete  or  remove  a  "system"  file 

ORENAh  Give  a  new  name  to  a  "system"  file 

CMCVE  hove  one  "system"  file  to  another 

(rename  a  "system"  file  to  another  existing 
"system"  file) 

The  basic  file  accessing  routines  are  called  FGET  and  FFUT. 
These  two  routines  control  the  actual  movement  of  data  between  the 
computer  memory  and  the  CLPAP.S  variable  anc  fixed  files. 


All  the  above  mentioned  file  manipulation  and  accessing 


routines  (written  in  FORTRAN )  are  at  the 
hierarchy  of  CLPARS  file  system  routines, 
routines  will  be  referred  to  as  level  I  routines 
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nt  a  step  above  the  system  cepencer.t  tile  routines  will  to  a 
set  ct  routines  that  the  CLPARE  application  programs  use  to  invoke 
the  mere  primitive  level  I  routines.  These  programs  will  be  known 
as  level  II  routines.  The  level  II  routines  have  the  quality  ci 
being  "system  independent . "  A  few  examples  of  some  of  these 
routines  are  as  follows: 

CPENTR  Cpens  an  CLPARE-  data  or  logic  tree 

(manipulation  routine) 

CREATR  Creates  an  CLPARS  data  or  logic  tree 

(manipulation  routine) 

CPENFX  Cpens  an  CLFAR5  fixed  file 

(manipulation  routine) 

TIGCAP  Gets  the  counts  and  pointers  from  a  node 

entry  in  the  tree  information  file 
(access  routine) 

I.ote  that  the  level  II  file  manipulation  routines  may  use 
level  II  file  accessing  routines.  CFENTR  is  still  considered  a 
level  II  file  manipulation  routine  because  it  uses  COPE!;  to  perform 
the  actual  system  file  open.  That  is,  CFEKTR  is  a  level  II  routine 
because  it’s  a  step  above  its  corresponding  file  manipulation 
routine,  CCPEN,  which  is  a  level  I  routine. 


- p. 
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|  The  following  paragraphs  give  additional  characteristics  cf 

these  routines. 

f 

c  Some  Level  II  file  accessing  routines  may  nave 
been  cesigned  to  perform  format  conversions  when 
cesirea  by  the  applications  program.  For  example, 

if  an  applications  program  requests  the  number  cf  i 

nodes  in  a  data  tree  to  be  returnee  into  an  integer 
variable  I.,  then  the  level  II  program  it  calls  will 
retrieve  the  number  cf  nodes  from  the  proper  tree 

-i 

information  file.  Since  all  data  is  stored  as 

"real,"  the  level  II  program  must  convert  the  1  ' 

number  of  nodes  to  an  "integer"  and  place  it  ir.  !. . 


Applications  programs  neea  not  "know"  the  format 
of  files;  i.e.,  they  do  net  need  to  knew  which 
element  of  a  logical  entry  contains  a  particular 
item  of  data.  They  do  need  to  know  the  name  ar.d 
calling  sequence  of  the  level  II  file  access 
routine.  The  reason  for  this  is  that  the  level  II 
file  accessing  routines  "know"  the  format  of  the 
CLPARS  files.  The  application  program  need  only 
"know"  the  name  and  the  calling  sequence  cf  the 
level  II  file  accessing  routine. 


I 
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c  Ii‘  mere  elements  are  aoded  to  a  logical  entry , 
previously  designed  level  II  file, accessing 
routines  rr.ay  r.ct  require  race  if  icaticr.  (i.e.,  i: 
the  adoptions  are  mace  at  the  end  cf  the  logical 
entry  ,  as  opposed  to  being  inserted  in  the  miccle 
c 1  the  logical  entry). 

c  All  files  utilized  with  this  system  will  have  the 
same  length  physical  record.  Level  II  file 
accessing  routines  are  unaware  of  this  length. 
Maximizing  this  length  improves  efficiency  by 
minimizing  actual  file  accesses;  minimizing  this 
length  leaves  more  computer  memory  space  fer 
applications  programs.  Fhysical  record  length  is 
a  machine-dependent  value.  (See  Appendix  F  for 
detailed  CLPAKS  I/C  notes  on  the  F.SX-1  1M  operating 
system . ) 


before  giving  a  more  aetailed  description  of  the  file  system 
routines,  two  tables,  which  are  used  by  these  routines,  must  be 
described . 

The  first  table,  called  the  File  Cede  Table  (PCI),  is  usee  to 
relate  a  number  to  a  file  name  known  to  the  particular  operating 
system.  Thus,  the  portable  CLPARS  system  will  be  able  to  refer  tc 
all  files  in  a  simple,  machine/system-ir.de pend er.t  numeric  code 
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system. 
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accessing 
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All  fixed  files,  which  are  cescritec  in  later  sections,  have 
the  following  rCLs: 
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For  variable  files,  another  scheme  is  used.  Fcr  each  user 
data  tree  there  is  an  entry  in  the  Tree  List  (TL)  file,  sr.c  icr 
each,  user  logic  tree  there  is  an  entry  ir.  the  Logic  List  (LL)  file. 
These  entries  contain  the  tree  name  sne  FCEs  fcr  the  two  files, 
representing  the  data  or  logic  tree.  Note,  the  file  cedes  fcr 
variable  files  are  net  preceternir.ed  like  the  file  cedes  fcr  fixed 
files . 


The  File  Code  Table  is  system  dependent  and  accessed  directly 
by  the  level  I  manipulation  routines  only.  Appendix  £  gives  the 
format  of  the  FCT  as  it  will  appear  under  the  F.SX-1  1M  operating 
s  ystem . 
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1  he  second  tatle  usee  by  the  file  rcutir.es  is  the  File  r ctess 
ar.d  Ccr.trcl  Table  (FACT).  This  table  serves  several  purposes,  all 


generally 

related 

tc  the  set  of  files  which 

arc 

"  c  p  e  r. "  cr 

accessible 

tc  an 

CLPAF.E  program  during  its  execu 

tier.. 

Ti.e  entry 

index  tc  tl 

i  i s  table 

is  a  File  Descriptor  number,  cr 

FID. 

A  r.  entry 

in  FACT  ccr.tair.s  the  "system"  file  narr.e  ,  the  "lexical  unit  number" 
assignee  tc  the  file  (Ll’h),  space  for  a  physical  reccrc  (Pi.ElFF), 
the  recorc  number  of  the  physical  reccrc  currently  in  the  buffer 
(CFFii.),  the  number  of  elements  in  the  file  header  (EM),  the  number 
of  elements  in  a  logical  entry  of  the  file  (LEAF),  ar.c  a  "put"  flag 
(FF)  which  incicates  that  a  change  has  been  made  by  a  "file  put" 
function  in  seme  portion  of  the  current  physical  record .  (See 
Figure  3-1)  The  FACT  table  is  incorporated  into  a  common  area  that 
is  available  to  all  level  I  routines. 

5.2.1  Level  I  hsnipul aticn  Routines  - 

CCPLK  locates  the  first  empty  entry  in  the  File  Access  and 
Control  Table  (FACT)  and  sets  a  file  descriptor  (FID)  to  point  tc 
that  entry.  fhe  file  code  (FCE)  for  variable  files  is  obtained 
from  the  tree  or  logic  list  files  before  calling  CCFEK.  The  header 
size  (HAL,  header  number  of  elements)  and  logical  entry  size  (LEM, 
logical  entry  number  of  elements)  of  the  file  must  be  given  sc  they 


IS 
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car  be  entered  into  the  FACT.  The  "put  flag"  (PF)  end  the  r.u.:ter 
cf  the  current  physical  record  (CFFh)  entries  cf  the  FACT  will  be¬ 
set  to  zero.  CCFEI.  obtains  a  "system"  file  name  from  the  File  Code 
Table  (FCT),  via  the  FCL,  anc  opens  a  "system"  tile.  The  logical 
unit  number  entry  within  the  FACT  is  also  set  by  CCFEI.. 

GCREAT(E)  creates  a  new  "system"  file  for  CLFARE  program  use. 
CCREAT  is  given  the  name  of  the  file  to  create  along  with  the 
"type"  cf  the  file.  The  "type"  indicates  that  the  file  is  one  cf 
the  following: 

1.  tree  information  file 

2.  tree  vector  file 

3.  logic  information  file 

4.  logic  value  file 

5.  fixed  file 

All  the  above  types  have  entries  placed  in  the  File  Code  Table 
(FCT).  The  entry  in  the  FCT  is  a  "system"  file  name,  crested  using 
the  "LAKE"  and  "TYPE"  arguments  cf  CCKEAT.  The  file  code  of  the 
created  file  is  returned  to  the  calling  program.  CCREAT  fills  in 
the  FACT  entries  and  returns  a  FACT  pointer  just  like  CCFEI.'. 

CCLCSE  first  checks  the  "put"  flag  entry  in  the  FACT  (for  the 
given  FID)  to  decide  whether  it  needs  to  write  out  the  current 
buffered  record.  It  then  frees  the  portion  of  the  FACT,  pointed  to 
by  the  given  file  descriptor,  and  performs  a  "system"  file  close. 
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CLLLLI  removes  an  existing  "system"  File  From  the  computer 
Of. ersting  system's  file  structure.  It  also  removes  an  entry  in  the 
File  Loce  Table  pointed  to  by  the  given  file  code  argument,  if  the 
celeted  file  is  a  variable  file. 

ChEIiAM  changes  the  name  of  the  "system"  File  name  within  the 
File  Ccie  Table  pointed  to  by  a  given  file  code. 

GKCVE  moves  the  "system"  file,  pointed  to  by  one  file  ccce,  to 
the  "system"  file,  pointed  to  by  another  file  code.  This 
essentially  is  a  "system"  renaming  function,  but  done  in  a 
different  manner  than  CfiEKAM.  (CREL'AK  is  used  when  the  new  name  of 
the  file  being  renamed  is  not  already  in  the  FCT  file.  To  insure 
that  there  are  no  duplicate  file  names,  CF.Ef.’Af-:  must  check  the 
entire  FCT  file.)  The  file  pointed  to  by  the  second  file  code  is 
eliminated  from  the  "system." 

General  Lotes:  The  contents  of  a  file  cannot  be  accessec 
unless  it  is  open  at  the  time  of  access  (the  maximum  number  of 
files  which  can  be  opened  simultaneously  is  limited  by  the  number 
cf  entries  in  the  FACT  and  any  particular  system  limitations).  A 
file  should  not  be  deleted  if  it  is  open.  File  deletion  does  net 
remove  an  entry  from  the  TL  or  LL  file;  that  is  the  application 
program's  responsibility.  In  renaming  files,  the  old  file  should 
be  closed  before  it  is  renamed;  the  new  file  is  net  opened  by 
ORENAK. 
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2.2.2  Level  i  File  ,-ccess  Loutir.es  - 

Cr.e  of  the  features  cf  FGET  and  FPUT  is  the  minimization  ci 
actual  physical  record  accesses.  A  description  cf  the  FGET 

procedure  follows. 

FGET  uses  a  file  descriptor  (FID)  to  determine  which  FACT 

entry  describes  the  file  to  be  accessed.  From  the  procedural 

arguments  specifying  the  logical  entry  of  the  file  and  the  first 
element  within  that  entry,  plus  information  in  the  FACT  entry 

(number  of  elements  in  header  and  number  of  elements  in  logical 
entry),  it  is  possible  for  FGET  to  compute  the  "absolute"  element 
address  in  the  file  of  the  first  element  to  be  retrieved.  Dividing 
this  address  by  the  number  of  elements  per  physical  record 
(constant  for  all  files)  will  give  the  physical  record  number 
containing  the  first  element.  Comparing  the  required  physical 
record  number  to  the  physical  record  number  currently  contained  in 
the  memory  resident  buffer  determines  if  the  element  requested  is 
already  in  memory;  if  it  is,  the  element  is  returned  to  the 
calling  program;  if  it  is  not,  a  new  physical  record  must  be  read 
into  the  t.ffer.  However,  before  reading  the  new  physical  reccrc, 
a  check  of  the  "put  flag”  determines  if  any  elements  cf  the  current 
physical  record  were  changed  by  a  write  (FPUT)  cperaticn.  If  so, 
the  memory  buffer  is  written  to  the  file  before  the  new  physical 
record  is  read  into  the  buffer. 


:-Fl:T  works  in  a  similar  manner. 
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FPUT  computes  the  "atsclute" 
element  ad  or  ess,  the  physical  record  number  and  the  "relative" 
ac cress  in  the  physical  record  number  of  the  first  element  to 
write.  The  computations  are  the  same  as  those  done  in  FCE7. 

If  the  required  physical  record  number  is  not  ir.  the  FACT 
physical  record  buffer  (memory  resident),  the  "put  flag"  is  checkeo 
tc  see  if  it  is  necessary  to  write  out  the  current  physical  reccrc 
buffer  before  reading  in  the  required  record.  If  the  "put  flag"  is 
set,  the  memory  buffer  is  written  to  the  file.  The  required 
physical  record  is  then  read  into  the  memory  buffer.  If  an 
end-of-file  occurs,  it  is  assumed  that  the  file  was  opened  for 
create,  ar.d  the  memory  buffer  is  zeroed  out.  Ar.y  ether  type  of 
read  error  causes  FFUT  to  exit.  If  the  required  physical  record 
number  is  memory  resident,  no  read  is  necessary. 

The  elements  tc  be  written  to  the  file  are  transferred  from 
the  calling  routine  buffer  to  the  FACT  physical  record  buffer.  The 
"put  flag"  is  set  to  indicate  that  elements  have  been  changed.  If 
there  are  more  elements  to  be  written  (elements  to  be  changed  cross 
block  boundaries),  the  current  physical  record  buffer  is  written  tc 
the  file  and  the  next  required  record  is  read  into  the  memory 
buffer.  The  process  continues  until  all  elements  have  teer. 
changed  . 
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3.2.3  Level  II  Routines  - 

Since  there  has  been  a  large  number  of  level  II  routines 
developed  tc  meet  the  needs  of  the  CLPAF.S  applications  programmer, 
it  is  impossible  to  provide  routine  names  and  parameters  in  tiiis 
document  (see  CLFARS  V-VI  Software  Feference  Manuals).  However, 
several  realistic  examples  are  shown. 

A  routine  naming  convention  is  used,  because  of  the  number  of 
routines  possible.  Those  level  II  routines  that  read  from  or  write 
into  a  file  have  names  of  five  or  six  characters  of  the  form  FFXKM 
or  FFXHMh,  where  FF  represents  the  file  name  type,  X  is  G  for  get 
(read)  cr  F  for  put  (write),  and  MM  or  MMM  is  a  mnemonic  for  the 
routine . 

For  example,  there  can  be  a  routine  which  returns,  as  an 
integer,  the  number  of  entries  in  the  tree  list  (TL)  file.  The 
code  for  this  routine  is  suggested  below. 

INTEGER  FUNCTION  TLGNCE  (FID) 

INTEGER  FID,  N 

f.  =  FGET  (FID,  C,  1,  1,  X) 

TLGNCE  =  X 
RETURN 

For  this  example,  we  have  assumed  that  the  number  of  the  entries' 
value  of  the  TL  file  is  contained  in  the  first  element  of  the 
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r.eacer.  The  value-  of  FID,  of  course,  came  from  opening  the  tree- 
list  tile.  This  example  illustrates  that  a  level  11  routine  car. 
c Lange  the  real  format  used  for  all  file  elements. 

As  another  example,  v.e  need  a  routine  tc  retrieve  the  rr.ear. 
vector  icr  a  data  set,  given  that  we  know  the  logical  entry  (LL) 
for  this  cata  set  in  the  II  file. 

SUbKCUTIM  TIGKt:  (FID,  LE,  MIH,  ABL'F ) 

IKTECER  FID,  FGET 

i:  =  FGET  (FIC,  LE,  1?,  MIH,  AEUF ) 

RETURN 


In  this  example,  we  have  assumed  that  the  mean  vector  starts  the 
17th  element  of  a  TI  file  entry. 
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Each  CLEARS  user  will  have  the  following  files  i 
user's  directory: 


Communications 

(CM) 

Tree  Information 

(TI) 

Tree  Vector 

(TV) 

Tree  List 

(TL) 

Logic  Information 

(LI) 

Logic  Value 

(LV) 

Logic  List 

(LL) 

Saved  Vector 

(SV) 

Saved  Transformation 
Matrix 

(SM) 

Display  Information 

(DI) 

Display  Value 

(DV) 

Projection  Vector 

(PV) 

Scratch  1 

(SI) 

History 

(HS) 

The  contents  of  the  first  nine  files  are  described 
in  this  section.  The  display  files  are  discussed  in 


r.  his/her 


in  detail 
Section  5. 


The  history  file  is  described  in  Appendix  E,  under  the 
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instrumentation  package. 

4.1  T!iL  CChMMCATIChE  (Cl.)  FILL 

The  C!.  file  contains  basic  CLFAR  system  information  t.-.at  will 
be  accessed  by  almost  all  cf  the  CLEARS  command  programs.  Cir.ce  is 
contains  no  "data",  it  cnly  has  a  h.eacier.  This  heacer  is  pictured 
in  Figure  4-1.  The  following  paragraphs  explain  the  concepts  cf 
current,  data  set,  current  logic  and  current  major  CLEARS  option. 

The  current  data  set  is  the  treensme,  node-name  pair  that  the 
user  works  with.  It  consists  of  all  the  vectors  ar.c  structure 
underneath  that  particular  node.  It  is  assigned  using  the  SETLE 
command,  which  prompts  for  the  name  cf  a  data  set. 

The  current  logic  is  the  logic  the  user  is  in  the  process  cf 
designing  or.  the  current  data  set,  or  using  to  evaluate  a  test  cats 
set.  In  the  portable  FORTRAN  version  of  CLFAF.S,  we  allow  more  than 
one  logic  file  per  data  set.  To  dc  this,  the  user  will  be  forced 
tc  assign  unique  names  to  all  logic  files.  To  begin  a.  new  logic 
the  command  NAMELCG  is  used;  to  restore  an  old  logic  the  command 
SETLCC  is  used . 

The  user  will  be  able  tc  store  several  logics  for  the-  same 
data  set.  They  may  be  complete  or  incomplete  logics.  If  they  are 
incomplete,  they  may  be  restored  as  the  current  logic  and 
completed.  V.hen  a  logic  is  being  designed  or  evaluatec ,  its  ecsigr. 
set  or  test  set  must  be  the  current  data  set. 
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Current 
Late 
Set 
Info  . 


Current 
Logic 
Ir.  fo  . 


1  -£ 

Current  Tree  nan. e 

C, 

Tree  Information  File  FCL 

1C 

Tree  Vector  File  FCL 

11-14 

Current  Locie  I.'ame 

15 

Entry  Table  Slot  Lumber 
of  Current  Lobe 

1 1 

NDIFi 

17-24 

Current  Logic  Lame 

25 

Logic  Information  File  FCL 

26 

Logic  Value  File  FCL 

27 

Lumber  of  Incomplete  Logic  Lodes 

2£ 

Empty  (area  for  future  use) 

29-4? 

Screen  Coordinate  Information 

48 

Prompt  flag  (C  =  short  prompt) 

(1  =  long  prompt) 

45 

Cne-space  Lin  Factor  (default  =  5) 

5C 

Two-space  Cutoff  Value 
(Gefault  =  5GC) 

51 

Instrumentation  flag 

52 

Instrumentation  Threshold 

55 

Current  CLPAPS  Option  if  ... 

54-63 

...  and  Option  Lame 

64-57 

CLPARS  directory  path  string 

Figure  4-1  The  Communications  File  Leaaer 
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Tht  current  major  LLF/.hC  cation  is  the  lest  major  CLFAi.C 
cor  ir.ar.c  that  was  use;..  It  is  "  rer.crr  berec "  so  ti.st  a  correct  set  of 
subsequent  options  may  be  cispiayec  tc  the  user.  The  determination 
cl  the  set  of  major  CLPAF.a  options  and  their  option  numbers  can  be 
1'cur.G  in  the  CFTIU!  test  file  (see  Appendix  E). 

For  ar.  explanation  cf  the  prompt  flap;  in  element  4£  cf  the  Cl. 
file,  see  Section  7.  £.2  of  the  CLEARS  V  Final  Report.  The  numbers 
stored  in  elements  £9  ar.d  5C  relate  tc  CLFAF.S  displays.  The  use  cf 
the  cr.e-space  bin  factor  is  described  ir.  Section  5.2.  The  two 
space  cutoff  value  cetermines  whether  a  cluster  plot  or  a  scatter 
plot  is  produced  on  a  two  space  display.  If  the  number  cf  vectors 
in  the  data  set  is  less  than  the  cutoff  value,  a  scatter  pict  will 
be  produced;  otherwise,  a  cluster  plot  will  be  produced  .  The 
default  cutoff  value  is  5CC.  The  instrumentation  flag  is  used  tc 
enable  and  display  the  CLFARS  instrumentation  package.  The  prompt 
flag,  bin  factor,  cutoff  value,  and  instrumentation  flag  may  be 
altered  by  using  the  command  CEEFALLT. 

A. 2  THE  ThEE  Il«F CRKATICh  (TI)  FILE(S) 

The  Tree  Information  file  contains  all  necessary  structural 
information  about  a  data  tree  as  well  as  the  mean  vector  ar.d 
covariance  matrix  for  each  ncce  cf  the  tree.  The  TI  file  consists 
of  a  fixec-length  header  portion  and  a  f ixed-length  entry  for  each 
node  in  the  tree  (see  Figure  ■4-2). 
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The  h-cacer  contains  the  number  cl'  nodes  in  the  tree  inducing 
the  senior  r.cce  (  m  el  trier,  t  1),  ice  c  irr.cn  sic  n  c  h  tr.c  vectors  (  i  r. 
element  i } ,  the  position  ir.  the  TI  file  cf  the  next  available 
(c-mpty)  er.tr}  (ir  element  3),  ar.c  the  next  open  entry  a:  the  end  cf 
the-  file  (  i r.  element  t ) . 

Ir.  order  tc  ciscuss  the  pointer  ir  element  5  cf  the  heaaer,  we 
must  first  explain  the  entry  table  and  the  meaning  cf  sr.y  pcir.ter 
ir.  the  TI  file.  '.■.her.  a  rede  is  placed  in  the  TI  file  (initially, 
cr  by  some  tree  manipulation  routine),  it  is  icentifiec  with  a  slot 
ir.  the  entry  table.  This  slot  contains  the  actual  entry  number 
that  the  node  resides  at  within  the  TI  file.  Any  pointer  to  a  noce 
will  point  to  the  slot  ir.  the  entry  table  with  which  it  is 
identified  ar.a  r.ct  tc  the  actual  entry  in  the  file.  The  slot  with 
which  a  node  is  identified  will  r.ct  change,  unless,  of  course,  the 
r.oce  is  deleted,  ir.  which  case  the  corresponding  slot  will  be 
zeroed  . 

The  key  feature  of  this  scheme  is  that  all  pointers  are 
independent  cf  the  actual  entry  position  of  the  nodes  ir.  the  TI 
file.  I.'oces  can  be  physically  moved  within  the  TI  file  ar.d 
pointers  residing  within  the  node  do  not  have  to  be  changed.  The 
only  change  necessary  is  a  change  to  the  slot  content  ir.  the  entry 
table  with  which  the  nodes  are  identified.  The  adciticn  cf  the 
entry  table  to  the  TI  file  header  has  greatly  simplified  many  of 
the  tree  manipulation  routines. 


fcru Lie  CLFAhS  Filing  Ltructurc 
71. L  TREE  II.F CF.iv ATIC:.  (7  1)  FILE(il) 

7 lie  senior  ncce  pointer  ir.  element  5  cf  the  Leader  then  points 
tc  the  slot  in  the  entry  table  that  is  identified  with  the  senior 
ncce.  7he  senior  node  is  accessec  by  first  obtaining  its  entry- 
position  from  that  slot.  The  entry  table  fellows.  It  contains 
slots  ter  ICC  ncaes,  which  is  the  maximum,  number  cf  neats  that  a 
cata  tree  may  possess  in  portable  CL PAF.S. 

For  each  node  in  the  tree,  there  will  be  an  entry  in  the  71 
file  (see  Figure  4-3).  The  large  set  of  pointers  is  designed  tc 
facilitate  movement  through  the  tree  and,  in  particular,  tc  en.atle 
programs  to  have  easy  access  tc  the  set  of  lowest  nodes.  The 
structure  is  completely  general;  any  node  cf  the  tree  can  be 
considered  as  the  senior  node  of  a  complete  tree.  A  diagram  of  the 
pointers  contained  in  elements  9  through  lb  cf  the  TI  file  entries 
is  exhibited  in  Figure  4-4  (remember  that  pointers  actually  point 
tc  slots  in  the  entry  table)  . 

The  vector  pointer  in  element  15  is  the  entry  number  cf  the 
first  vector  in  the  list  of  vectors  (within  the  TV  file) 
corresponding  to  a  given  lowest  node.  If  the  node  is  not  a  lowest 
node,  this  pointer  is  C.  For  debugging  and  maintenance  reasons, 
each  node  points  (in  element  16)  back  to  the  slot  in  the  entry 


table  with  which  it  is  identified. 
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Figure  E-3  The  Tree  Information  File  Er.  try 
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Figure  H-H  Pointers  in  the  TI  file  entries 


Ac c i t ior. el  Considerations  - 

The  name  c f  each  node  must  be  distinct  and  consist  cf  cr.e  tc 
four  characters  (blank  padding  v:i  1 1  occur  fcr  "short" 
names).  The  first  character  cf  the  r. arr.e  will  be  the  cr.e 
displayed  on  one-space  or  twc-space  displays.  There  arfc  <-( 
displayable  characters  in  the  1577  FORTRAN  standard.  Since 
only  lowest  nodes  are  used  in  such  displays,  a  maximum  cf  >-5 
lowest  nodes  will  be  allowed  ('?’  is  used  for  prompting 
purposes).  An  intermediate  node  can  begin  with  the  same 
character  as  another  intermediate  cr  lowest  node,  but  two 
lowest  ncaes  must  begin  with  distinct  characters.  The 
limitation  on  lowest  nodes  implies  a  maximum  cf 
approximately  50  nodes  in  an  CL PARS  data  tree.  These 
limitations  can  be  eased  (cr  further  restricted)  by  changing 
the  program  (LNICL'D). 
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t  .  hcutir.es  that  perform  manipulation  with  a  cats  tree  usually 
store  the  entry  table  within  a  program  array,  so  as  tc  have 

immediate  access  tc  the  entry  position  cf  all  nodes  ir.  the 

tr  ee  . 

c.  Before  nebes  are  entered  into  a  newly  createc  TI  file,  the 

entry  table  is  zeroed  out  so  that  no  extraneous  information 

exists  in  it. 

d.  when  a  node  is  deleted,  or  when  several  nodes  are  combined 
into  one  node,  entry  spaces  may  be  left  in  the  II  file.  In 
these  cases,  it  is  up  to  the  individual  program  tc  compress 
the  file  or  to  leave  the  spaces.  In  the  latter  case, 
element  2  of  the  TI  file  header  will  point  to  the  first  fret- 
entry  and  the  rest  of  the  free  entry  areas  will  be  linked. 
The  last  free  entry  area  will  always  occur  after  the  last 
filled  entry,  and  is  pointed  to  by  element  B  of  the  TI 
header.  For  a  more  complete  discussion,  see  Section  B.3. 
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Storage  cl'  the  Covariance  tatrix: 

Let  C  be  the  covariance  matrix  for  a  class  cf  vectors 
of  cimension  n  with  elements  C(i,j).  Since  C  is  symmetric 
(i.e.,  C  (  i  ,  j  )  =  C  (  j  ,  i  )  for  all  ’  i  ’  and  ’  j  •  from  1  to  ’  r.  ’  )  , 
it  is  only  necessary  tc  stcre  the  lower  triangular  portion 
of  C.  ke  shall  do  this  in  a  cne-dirnensionai  array,  callec 

la  • 

The  order  in  which  C  is  stereo  in  A  is  C(1,1), 

C  (  r. ,  1 )  j  C  ( 2  ,  c )  ,  »  •  •  ,  C  (  n  ,  c. ) )  C  (  p, ,  p )  ,  .  .  •  ,  C  (  n  ,  ^ )  j  •  •  •  * 

C(n-1,n-1),  C(r.,n-1),  C(n,n).  That  is,  the  columns  of  the 
lower  triangular  portion  of  C  are  stored  one  after  the  other 
in  their  natural  order.  The  problem  is  tc  find  a  formula 
for  a  given  C(i,j)  that  will  yield  a  ’k’  such  that 

C( i  ,  j)  =  A(k) 

The  address  of  an  element  cf  the  last  row  and  jth 
column  of  an  (n  x  n)  matrix  is  given  by 

Q(n,j)  =  jn 

To  address  a  position  ’  i’  in  the  jth  column  that  h  r.ct 
in  the  lest  row  (i  <  r.)  ,  we  have  to  subtract  off  tne 

distance  (n-i)  which  gives  us 


C  (i,j)  =  jr.  -  (n-i) 
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ilcte,  when  'i'  equals  '  r. '  we  get  cur  first  equation 
again . 

Now,  when  we  deal  with  only  the  lower  triangular 
portion  of  a  square  matrix,  we  will  have  to  subtract  off  a 
little  mere  ares.  Again,  we  start  with  the  formula  that 
gets  us  the  address  of  the  last  row  in  the  jth  column  of  a 
square  matrix  and  modify  it  sc  it  looks  as  follows 

C  (i,j)  :  jn  -  <extra> 

where  <extra>  means  all  the  array  positions  in  the  upper 
triangular  region  of  the  matrix,  preceding  (and  including) 
the  jth  column  (see  Figure  4-5) 

L ex tr a>  -  (j  —  1)  +  (j  —  2)  +  ...  +  1 

The  sum  of  the  numbers  1  to  S  is  given  by 

Sum  (S)  =  S  (5+1 )/2 

Therefore,  <extra>  =  (j-1)  (j)/2 

and  C  (n,j)  =  jn  -  j(j-1)/2 


*H  O' 


Figure  4 -5  The  Positions  ot  the  Covariance 
(C(ij),  i>  =  j)  ,  in  the  arra>  A 


f*  atr  ix 
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Tc  address  position  ’  i  ’  ir  the  jth  column  ct  the  lower 
triangular  pcrtior.  cf  tills  matrix  (i  >=  j)  that  is  r.ct  ir. 
the  last  row  (i  <  r.),  we  have-  to  subtract  off  the  same 
distance  (n-i)  as  we  a  id  in  the  previous  case.  iicr.ce,  fer 
(i  >  =  j),  the  position  of  C  (i,j)  in  array  A  is 


k  :  jn  -  j(  j-1  )/2  -  (r.-i) 


A. 2. 2  numerical  Example  - 


Consider  the  following  simple  data  tree  called  XEXAMFLE 


dimension  four. 


c  #*##  (senior  node) 


o  AI.'CD 


c  EKCE 


c  CI.CD 


o  Eh  CD 


o  Eli  CD 


DKCD  and  LiiCE  have  been  created  by  structure  analysis 
performed  on  Al.CD.  The  contents  of  the  TI  file  for  this  example 


are  shown  in  Figure  4-5a. 
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4.2.3  Creating  Lew  Trees  Frcrn  Cld  Trees  - 

The  CLPAF.S  data  tree  entry  table  plays  an  important  role  when 
creating  a  new  cata  tree  from  a  portion  of  an  existing  data  tree. 
Its  usefulness  comes  in  the  form  of  minimal  structural  pointer 
changes . 

For  example,  the  portion  of  an  existing  tree  (TREE1)  used  to 
create  a  new  tree  (TREE2)  contains  nodes  2-4-5,  where  2  is  defined 
to  be  the  "current  data  node"  (see  Figure  4-6).  The  slot  numbers 
cf  the  nodes  that  make  up  the  new  tree  will  be  identical  to  their 
corresponding  slot  numbers  found  in  the  old  tree.  However,  note 
that  the  contents  of  the  entry  table  slots  (entry  numbers)  in  the 
new  tree  differ  from  those  found  in  the  old  tree.  The  new  slot 
contents  relect  the  actual  position  cf  the  nodes  obtained  from  the 
old  tree. 

A  few  more  changes  are  necessary  to  complete  the 
transformation  of  old  to  new.  Each  node  in  the  new  tree  requires  a 
new  node  level.  For  those  nodes  that  are  lowest  nodes,  a  new 
vector  pointer  is  needed  (i.e.  vectors  are  transferred,  too).  The 
first  lowest  node  in  the  new  tree  must  have  its  lowest  node  back 
pointer  set  to  -1  (end  link  indicator)  and  the  last  lowest  node 
must  have  its  lowest  node  link  pointer  also  set  to  -1.  The 
"current  node"  of  the  old  tree  is  now  the  senior  node  of  the  new 
tree.  Thus  the  node's  name  must  be  changed  to  »*##«',  the  name  of 
the  senior  node  in  every  CLPARS  data  tree.  Also,  the  parent 
pointer  sibling  pointer  of  the  new  senior  node  must  be  set  to  zero, 
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Figure  4-6  Creating  a  tree  relying  on 
data  tree  entry  table 


Portable  CLPAhS  riling  Structure  --  4 
THE  THEE  ILFCRLATICI.  (II)  FILE(S) 

indicating  there  are  r.o  parents  or  siblings.  Finally,  the  senior 
node  slot  number  (feuna  ir.  the  71  header  ci'  the  new  tree)  is  set  tc 
point  to  the  senior  note. 

Ey  using  this  method  of  data  tree  creation,  all  the  sir»‘  "tral 
pointers  in  the  new  tree  do  not  have  to  be  changed.  An  example  of 
this  method  can  be  found  in  the  subprogram  I.XFRf: . 

4.2  CL PAHS  FILE  "FREE"  LISTS 

In  the  logic  and  data  tree  files  of  CLEARS  (and  seme  "fixed" 
files),  we  have  the  concept  of  a  "free"  list  of  entries  or  nodes. 
These  free  entries  or  nodes  at  one  time  were  "active"  within  the 
tree  structure,  but  were  subsequently  deleted,  or  made  "inactive". 
These  inactive  entries  can  now  be  used  when  a  new  entry  or  ncce  is 
to  be  added  to  the  tree. 

Within  the  header  of  the  tree  files  that  have  "free"  lists 
(the  Tree  Vector  file  does  not  have  a  "free"  list),  resides  the 
information  necessary  to  maintain  the  list.  This  information 
consists  of  a  pointer  to  the  head  of  the  free  list,  a  pointer  tc 
the  end  of  the  free  list  (actually  the  end  of  the  file),  and  the 
number  of  active  entries  or  nodes  in  the  tree. 

Each  entry  or  node  in  the  "free"  list  has  a  pointer  tc  the 
next  entry  or  node  in  the  list  (this  is  a  one  way  directional 
list).  This  pointer  resides  as  the  first  element  in  the  entry  or 
node.  (See  Figure  4-7). 
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Figure  4-7  Free  List  of  a  Tree  File 
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'..her  the  Tree  list  is  empty,  the  pointer  tc  the  head  cf  the 
free  list  arc  the  pc ;  '  or  tc  the  ena  cf  the  free  list  will  both  te 
pointing  tc  the  er.c  cf  the  file  Lhen  sr.  "active"  entry  teccrr.c-s 
"inactive"  cr  celeted  ,  it  is  enterec  into  the  free  list  in  the 
fcllouing  manner: 

1.  The  pointer  tc  the  head  cf  the  free  list  is  placed  in  the 
first  element  of  the  deleted  entry. 

2.  The  pointer  to  the  head  of  the  free  list  is  changed  sc  it 
points  to  the  deleted  entry. 

3.  The  number  of  "active"  elements  in  the  tree  is  decremented 
by  one. 

When  a  new  entry  is  to  be  added  to  a  tree,  the  free  list  is 
consulted  first. 

If  the  pointer  to  the  head  of  the  free  list  is  equal  to  the 
pointer  at  the  end  of  the  free  list,  then  there  are  no  "inactive" 
nodes  within  the  tree.  Therefore,  the  tree  (file)  is  extended  to 
accommodate  the  new  entry,  and  both  the  "head"  and  "end"  pointers 
of  the  free  list  are  reset  to  point  to  the  end  of  the  file.  The 
number  of  elements  in  the  tree  is  incremented  by  one. 
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However,  if  the  free  list  contains  sene  "inactive"  renters 
(i.e.,  "head"  not  equal  to  "end"),  the  "head"  pointer  is  usee  to 
obtain  its  new  value  from  the  "inactive"  entry  to  which,  it  is 
pointing.  Again,  the  number  of  elements  in  the  tree  is  incremented 
by  one.  (Note:  the  number  of  elements  in  a  free  list  can  be  fcunc 
by  adding  one  to  the  total  number  of  "active"  elements  in  the  tree 
and  subtracting  that  quantity  from  the  "end"  pointer.) 

4.4  THE  TREE  VECTOR  (TV)  FILE 

The  vectors  of  a  data  tree  are  stored  in  its  Tree  Vector  file. 
The  vectors  are  grouped  together  by  lowest  node  to  facilitate 
access  to  the  set  of  vectors  in  a  lowest  ncae  and  to  free  the  TV 
file  of  pointer  storage  (see  Figure  4-8). 

The  header  of  the  TV  file  contains  the  last  logic  designed  (or 
evaluated)  on  the  tree  as  well  as  the  file  codes  of  the  files  that 
make  up  that  logic  tree.  It  also  contains  a  pointer  to  the  end  of 
the  file.  An  entry  in  the  TV  file  is  identified  with  a  vector.  In 
it,  the  vector  is  stored  along  with  its  ID,  the  first  character  of 
the  lowest  node  that  the  vector  resides  in  and  its  temporary  logic 
indicator  (see  Figure  4-S).  The  temporary  logic  indicator  will 
contain  the  node  number  that  the  vector  was  placed  at  from  the  last 
logic  applied  to  the  tree  (except  for  nearest  neighbor  logic). 
This  element  will  be  used  during  logic  design  or  evaluation  to  keep 
track  of  the  logic  node  at  which  the  vector  currently  resides. 
This  is  necessary  because  a  class  may  have  vectors  in  several  logic 
nodes  during  logic  design,  and  during  evaluation  it  is  a  convenient 
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Figure  4-8  The  Tree  Vector  File 
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way  of  keeping  track  of  the  results.  Moreover,  if  a  logic  design 
is  not  completed  in  a  given  user  session,  then  the  lowest  logic 
node  that  each  vector  resides  in  is  saved  in  the  temporary  element 
until  the  next  session.  The  logic  will  not  have  to  be  rc-evaiuatec 
before  the  logic  design  is  resumed. 

Note  that  the  length  of  a  TV  file  logical  entry  is  three  more 
than  the  dimensionality  of  the  vector  and  essentially  depends  on 
the  dimensionality .  This  dependency  presents  no  difficulty  since 
the  dimensionality  is  stored  in  the  Tree  List  file  entry 
corresponding  to  the  data  set. 

A. 5  THE  TREE  LIST  (TL)  FILE 

The  Tree  List  file  is  a  list  of  the  data  trees  that  the  user 
has  in  his  directory.  It  has  a  two  element  header  that  contains 
the  number  of  entries  (data  trees)  in  the  file,  and  an  alphabetic 
list  pointer.  Each  entry  corresponds  to  a  data  tree.  An  entry 
contains  two  File  Codes  (FCD)  representing  the  files  that  make  up 
the  data  tree,  the  dimension  of  the  tree,  space  for  an  8-character 
name  of  the  tree,  and  an  alphabetic  list  pointer.  See  Figure  L-1C. 

When  a  data  tree  is  added  to  the  system,  its  Tree  List  entry 
is  placed  at  the  bottom  of  the  Tree  List  file.  When  a  data  tree  is 
deleted  from  the  system,  its  entry  in  the  Tree  List  file  is  filled 
by  the  last  entry  in  the  file,  and  the  count  is  decremented  by  1. 
Consequently,  no  free  list  is  maintained  in  this  file. 
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The  alphabetic  list  pointers  are  used  to  keep  the  list  entries 
in  an  "alphabetic"  order.  All  new  entries  to  the  TL  file  are 
"placed"  in  the  proper  order  via  these  pointers. 

4.6  THE  LOGIC  IKFCRKATICM  (LI)  FILE 

For  each  logic  tree  that  exists  in  portable  CLPARS  (i.e.,  for 
each  logic  tree  listed  in  the  Logic  List  (LL)  file)  there  will 
exist  a  Logic  Information  (LI)  file  and  Logic  Value  ( L V )  file. 
These  files  have  a  parallel  in  the  TI  and  TV  files  associated  with 
each  data  tree.  The  LI  file  contains  general  information  about  the 
logic  tree  and  its  structure;  the  LV  file  contains  the  actual 
logic  (decision  criteria)  for  each  node  of  the  logic  tree.  In  this 
section  the  LI  file  is  discussed. 

The  header  part  of  the  LI  file  has  a  fixed  length;  the  length 
is  a  function  of  the  maximum  number  of  "displayable"  classes  (i.e., 
lowest  nodes  in  a  data  tree)  that  ~e  allowed  for  any  data  tree. 
Figure  4-11  shows  the  content  of  the  header,  assuming  50  is  the 
maximum  number  of  classes  allowed. 

Host  of  the  content  of  the  header  is  self  explanatory.  NAN 
(next  available  node,  element  15)  is  the  entry  number  (in  the  body 
of  this  file)  for  the  next  node  to  be  defined.  In  general,  HAL 
will  be  one  greater  than  fifJU  (number  of  nodes  used,  element  17); 
it  will  only  be  different  in  the  cases  where  certain  nodes,  already 
having  logic  defined,  have  been  deleted.  The  current  logic  node  in 
element  1£  is  only  used  in  conjunction  with  the  design  of  1  cr  2 
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Figure  4-11  The  Logic  Information  File  Header 
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space  group  logic  (this  logic  design  is  a  two  step  process  which 
might  net  be  completed). 

The  entries  in  the  body  of  the  LI  file  each  describe  a  node  cf 
the  lcgic  tree;  the  length  of  these  entries  is  fixed  and 
independent  of  any  data  set  parameters  (e.g.,  the  vector 
dimensionality  or  the  number  of  classes)  ,  but  it  is  machine 
dependent  because  of  the  classes-preser.t  bit  map,  which  is 
described  later.  The  logic  node  number  cf  a  node  will  be  the  same 
as  its  logical  entry  number  in  the  LI  file.  This  gives  a  simple 
and  unique  way  of  assigning  logic  node  numbers.  Figure  4-12  shows 
the  content  and  format  of  an  LI  file  entry. 

The  following  list  shows  the  logic  type  code  of  the  current 
CLPAKS  logics,  along  with  the  appropriate  subtype  codes.  (Logic 
type  and  subtype  codes  are  elements  of  the  LI  file  entry)  . 


Logic  Code  Type 

0  -  undefined  (incomplete) 

1  -  pairwise  logic 

2  -  group  logic 


1  -  one-space 

2  -  two-space 

3  -  Boolean 

3  -  nearest  mean  vector  logic 

4  -  closed  decision  boundary 

5  -  nearest  neighbor 
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Element 


1 

Logic  Type  Cede  (or  Entry  Link) 

2 

Logic  Sub-Type  Code 

3 

Option  Lumber  of  the  routine  that  created  the  logic 
at  this  node  (0  if  lowest  node) 

4 

Node  Level  (Senior  Node  is  Level  0) 

5 

Number  of  Nodes  Eelcw  this  Lode  at  Next  Level 

6 

Entry  Number  of  Parent  Node  (0  for  Senior  Node) 

7 

Entry  Number  of  First  Child  Node 

8 

Entry  Lumber  of  Next  Sibling 
(0  if  No  Next  Sibling  Node) 

9 

Entry  Number  (in  LV  File)  for  Start  of 

Decision  Logic  for  this  Node 

1C 

Entry  Number  (in  LV  File)  for  Reject  Strategy 
for  this  Node  -  0  if  No  Reject  Strategy 

1  1-14 

Original  Design  Data  Set  Class  Name 

for  this  Node  (only  for  lowest  nodes) 

15-18 

Reassociated  Class  Name 

for  this  Node  (only  for  lowest  nodes) 

15 

Modified  Logic  Flag 

20 

Number  of  Classes  Present  at  Mode  (0-for  reject) 

21-  ? 

Bit  Map  Designating  Classes  Present  at  this  Node 

Figure  4-12  The  Logic  Information  File  Entry 
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Since  pairwise  logic,  nearest  mean  vector  logic,  clcsec 
decision  boundary,  ana  nearest  neighbor  logic  have  no  subtypes  of 
logic,  their  subtype  code  will  be  zero  (rr.ear.s  undefined). 

Closed  decision  boundary,  however,  does  have  a  "sub-block" 
code  that  is  found  in  an  element  in  the  LV  file  (because  nodes  in  a 
closed  decision  boundary  logic  are  allowed  to  have  mere  than  one 
type  of  decision  boundary).  These  sub-block  codes  are  as  follows: 

1  -  hyperrectangular  sub-block 

2  -  hypersphere  sub-block 

3  -  hyperellipscid  sub-block 

If  the  value  of  the  logic  type  code  is  negative,  it  indicates 
that  the  node  had  been  defined  and  subsequently  deleted  and  the 
value  is  now  a  link  pointer  to  the  next  available  node  entry.  This 
is  usee  in  conjunction  with  HAN  and  HI.'U  elements  of  the  header  and 
prevents  lost  "holes"  in  the  entry  portion  of  the  file. 

Elements  containing  node  level,  first  child  node,  and  next 
sibling  node  facilitate  searching  the  logic  file  entries  for 
drawing,  and  listing  or  deleting  logic  nodes. 

Elements  9  snd  1C  are  the  entry  numbers  in  the  LV  file  for  the 
first  entry  containing  the  logic  decision  criteria  and  the  lcgic 
for  the  reject  strategy,  if  it  exists  for  this  node. 
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For  completed  logic  nodes  (i.e.,  nodes  with  only  s  single 
class  present),  elements  11  through  1A  will  contain  the  name  of  the 
class  at  this  node  (design  data  act  class  name).  If  it  happens  to 
be  a  reject  node,  the  name  of  the  "class"  will  be  "*#**";  although 
this  is  also  the  name  of  the  senior  node,  there  is  no  conflict. 
The  type  of  logic  code  for  a  completed  node  will  be  0  or  undefined, 
since  there  is  no  logic;  there  may  be,  however,  a  reject  strategy 
defined.  Elements  15-1  C  contain  a  class  name  to  be  associated  with 
the  original  data  class  ( reassociated  class  name).  This  name  may¬ 
be  used  during  logic  evaluation  to  associate  a  test  data  class  to 
the  original  design  data  class.  Luring  logic  creation  the 
reasscciated  class  name  and  the  original  design  data  set  class  name 
are  identical.  The  reasscciated  class  name  may  be  changed  by  the 
command  REASL'AKE. 

The  classes  present  bit  map,  which  starts  at  element  £1,  is 
one  place  where  it  is  necessary  to  deviate  from  the  standard  method 
of  using  real  format  words  for  each  element  of  a  file.  This  item 
is  a  binary  string  equal  in  length  to  the  maximum  number  of  classes 
allowed  ir.  the  system.  If  the  ith  bit  of  the  string  is  is  a  one, 
it  indicates  that  the  ith  class  (in  the  list  of  class  names  in  the 
header,  starting  at  header  element  23)  is  present;  if  the  bit  is 
zero  the  class  is  r.ot  present.  To  use  a  single  real  word,  for  each 
class  at  each  node,  is  felt  to  be  excessive  in  storage  space. 
Thus,  a  machine  dependent  (because  of  word  length)  scheme  is 
utilized  for  this  bit  map.  (Cn  the  PDP-11  machines  this  bit  map 
will  be  contained  in  two  real  elements).  For  a  reject  node,  the 
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bitmap  is  undefined  and  the  number  of  classes  present  is  zero.  For 
a  lowest  (completed)  ncce,  the  bitmap  is  redefined  and  the  number 
of  classes  present  is  one.  For  this  type  of  r.oce,  the  first 
element  of  the  bitmap  contains  a  pointer  into  the  list  cf  design 
ante  set  class  names  found  in  the  LI  header.  The  pointer  car.  be 
usea  to  obtain  the  name  of  the  class  that  is  associated  with  the 
logic  node.  The  pointer  is  also  used  as  an  "assigned  class"  index 
during  logic  evaluation. 
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(LI  File  Initialization) 

'.-.her.  a  logic  file  is  created  by  the  command  i.AFELCG,  the  LI 
file  sr.c  the  LI  file  will  be  crestec  .  f.AFtLCC  will  set  the 
following  values  in  the  LI  file: 


Lane  of  cesign  data  set  (ECS) 

Data  Set  Eimensicnal ity  (NDIM) 

The  number  of  classes  in  the  data  set  (L'CLAS) 

The  next  available  node  (NAN=2) 

Next  open  entry  at  enc  of  file  (NCE=2) 

Lumber  of  nodes  used  (NLU=1) 

Reassociated  Lames  Flag  (Rt.'F  =  0) 

List  of  Lowest  Lode  Class  Lames 
List  of  Class  A  Priori  Probabilities 

The  above  values  are  placed  in  the  header;  those  mentioned 
below  are  put  in  the  first  entry,  which  is  the  senior  node  of  the 
logit  tree. 


Logic  type  code  (=  0) 

Node  level  (=  0) 

Number  of  nodes  below  (=  C) 

Ent; y  number  of  parent  (=  C) 

Number  of  classes  present  (=  NCLAS) 

The  bit  map  which  indicates  all  classes  present 
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The  LY  file  of  a  logic  file  pair  contains  the  parameters  or 
variables  which  define  the  actual  cecision  logic  criteria  fcr  any 
r.cde  of  a  logic  tree.  The  entries  are  pointed  to  by  the  node 
entries  in  the  LI  file.  Entries  of  the  LV  file  also  contain  the 
blocks  which  specify  reject  strategy  logic,  if  used  at  ar.y  node. 

In  keeping  with  the  filing  system  conventions  established  for 
portable  CLEARS,  all  entries  in  the  LV  file  are  of  the  same  length; 
this  length  is  established  at  the  time  of  creation  and  is  a 
function  of  the  dimensionality  of  the  data  set  on  which  the  logic 
is  being  designed.  However,  the  different  types  of  logics  require 
different  amounts  of  storage.  To  accommodate  this  flexibility 
within  the  LV  file,  the  design  is  such  that  a  logic  block  (the 
definition  criteria  for  the  logic  of  a  node)  may  be  contained  in  a 
number  of  entries  of  the  LV  file. 

The  entry  in  the  LV  file  for  a  node  contains  the  entry  number 
of  the  first  entry  of  the  logic  block  in  the  LV  file.  The  first 
element  of  an  LV  file  entry  is  a  link  which  points  to  succeed 
entries  of  that  logic  block.  A  zero  in  the  first  element  indicates 
that  this  entry  is  the  last  entry  of  a  logic  block.  This  linking 
is  necessary  for  the  efficient  deletion  or  charge  of  the  decision 
logic  at  a  node. 
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The  length  of  an  entry  in  the  LV  file  is  LDIL+2  with  a  rr.ir.xr.uir. 
length  of  12  elements.  This  length  was  chosen  after  analyzing  tr.e 
space  requirements  for  the  different  types  of  logic  blocks  ana 
optimizing  the  choice  of  length  as  a  trade  off  between  unused  space 
and  complicated  structure.  The  minimum  length  of  12  is  needed  in 
the  Fisher  pairwise  logic  block. 

Entries  that  comprise  a  logic  block  do  net  have  to  be 
contiguous;  since  they  are  forward  linked  to  each  other,  they  dc 
net  have  to  be  sequential.  They  will  be  non-sequential  only  in  the 
cases  where  a  previously  designed  logic  has  been  deleted.  Elements 
in  the  header  and  the  link  element  of  each  entry  implement  this 
capability. 


The 

LV  file  he 

ader  cont 

.ains  three  elements; 

these 

are 

defined 

in  order 

below : 

Element 

Contents 

Ini 

tial 

Value 

1 

NEU 

total  number  of 
entries  actively  used 

C 

2 

NOE 

next  open  entry  at  end 
of  file 

1 

3 

NETU 

next  entry  to  use 

1 

NCE  will  differ  from  NETU  only  if  there  has  been  a  deletion  of 
defined  logic.  The  total  number  of  entries  that  could  be  found  in 
a  "free"  list  (deleted  entries  list)  is  found  by  NOE  -  (NEU  +  1). 
Initial  values,  set  when  the  LV  file  is  created,  are  shown  at  the 


right 
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The  use  cf  the  first  element  of  each  entry,  the  next  entry 
link  or  link  element  is  similar  in  all  cases.  If  the  number  is 
positive,  it  is  the  entry  number  of  the  next  entry  in  the  block; 
if  it  is  zero,  it  is  the  last  entry  used  by  a  block;  if  it  is 
negative,  it  indicates  that  it  was  a  deleted  entry,  but  its 
absolute  value  is  still  treated  as  a  link  (now  a  link  of  deleted, 
and  available  for  reuse,  entries).  The  last  entry  of  the  string  of 
deleted  entries  contains  a  link  to  KOE,  the  next  entry  after  all 
used  entries.  (See  Section  4.3  on  "free"  lists). 

In  addition  to  the  link  element  which  forward  links  all 
entries  containing  logic  for  a  node,  certain  entries  may  contain  a 
link  to  a  particular  portion  of  the  logic.  This  is  done  to 
facilitate  getting  to  certain  sections  of  the  more  complicated 
types  of  logic  or  logics  which  permit  suboptions  (e.g.,  the  KM V 
command).  Figures  4-13  and  4-13a  illustrate  this  multiple  linking. 
Note,  in  the  Fisher  Fair  logic  block  example  in  Figure  4-13A,  there 
are  three  forward  links  with  a  value  of  zero;  one  for  the  main 
logic  block,  two  for  auxiliary  logic  regions.  Each  represents  the 
last  entry  of  their  respective  regions. 

Figures  4-14  through  4-24  describe  the  file  entry  formats  for 
different  types  of  logic  blocks. 
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A 

1 

1 

1 

1 

1  1 

...  — >  K 

1  1 

1  < 

1  1 

1 

1 

!  1st  Entry 

1 

i 

1  1 

I  i 

1  1 

I  i 

1  t 

I  1 

1  l 

1  nth  Entry  ! 

l  t 

1  ( 

1 

1 

» 

— 

U 

-- 

1 

1 

!  2nd  Entry 

#  #  #  * 

n+1  Entry 

\ 

* 

*  _ - 

* 

* 

<- 

* 

<- 

I 

n  r. 

* 

» 

!  3rd  Entry 

* 

n+2  Entry 

• 

* 

* 

» 

• 

• 

*  ....... 

<- 

• 

*  *>  T 

-- 

Normal  Link  -- 

—  > 

Multiple  Link 

*  *  *  > 

n+3  Entry 

Z 


0 


LAST  Entry 


< 


Figure  4-13  Multiple  Linking  Viithin  A  Logic  Elock 
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Logic  block 

heacer  (pointer  to  here  found  ir.  LI  entry) 

I 

////////////// - >//////////////// >  . . , 

//////////////  /  / 

//////////////  /  node  number  / 

/  class  pair  /  /  associations  / 

--/  links  ptr.  /  /  / 

,  //////////////  //////////////// 


/////////////  — 
/  / 

/  noce  nbr.  / 

/  assoc.  / 

/  / 

///////////// 


■>///////////////////////////////<■ 


from  last 
entry  of 
C  PL 


- /  / 

- /  Class  Fair  Links  / 

/  / 

/  / 

/////////////////////////////// 


/ - >. . .  to  next  entry 

/  of  class  pair 

J  links  ( CPL ) 


■>/////////////  — 
■  -/  aux  .  ptr.  / 

/  / 

/  (cph)  / 
///////////// 

-/////////////<- 
/  / 

/  fisher  / 

/  direction  / 

/  / 
///////////// 

•>/////////////-■ 
/  / 

/  fisher  / 

/  orthoganal/ 

/  / 
///////////// 

cl  .vs.  c2 


•>/////////////-- 
/  class  pair/ 

/  header  / 

/  (cph)  / 
///////////// 

-/////////////<• 
/  / 

/  fisher  / 

/  direction  / 

/  / 
///////////// 

■  >/////////////- 
/  / 

/  fisher  / 

/  orthoganal/ 

/  / 
///////////// 

cl  .vs .  c3 


■  >////////////—>  ...  ///  zero  // / 
/  /  /  / 

/  optimal  discriminant  logic  / 
/  /  /  / 

////////////  iiiiiiiiiiii 


..  /////////////- 

- /  aux .  ptr .  / 

/  / 

/  (cph)  / 
///////////// 


-/////////////<- 
/  / 

/  fisher  / 

/  direction  / 

/  / 
///////////// 

->///  zero  //// 

/  / 

/  fisher  / 

/  orthoganal/ 

/  / 
///////////// 

c ( n- 1 )  .vs.  c ( n ) 


-->//////  zero  ///// 
/  / 
/  any  auxiliary  / 
/  logic  region  / 
///////////////// 


Figure  4-13A  Example  of  Fisher  Fair  Logic  Elock 
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Entry  Lumber  1 

Element 

Con ten 

1 

2 

3 

4 

5 

6 
7 


Link  Element  -  Entry  Lumber  of  Second  Entry 

Lumber  of  Eoundaries  (=  1  or  2) 

Lode  Lumber  Associated  kith  Right-Host  Region 

Lode  Number  Associated  kith  Left-Host  Region 

Node  liumber  Associated  kith  Kiddle  Region 
(if  2  Eoundaries) 

Right  Threshold  Value 

Left  Threshold  Value  (if  2  Boundaries) 


Entry  Lumber  2 
Element  Content 


1 


2 

I 

I 

I 

•  I 

> 

f 

•  I 
I 

NEIK  +  1  - 
NDIM+2 


Link  Element  (=  0) 


NDIM  liscriminant  (Projection  Vector) 
Coefficients 

Number  of  Kesurements  Used 


Figure  4-14  Cne-Space  Croup  Logic  Elock  Format 


Fcrtabie  CLPAFS  Filing  Structure  —  4 
THE  LCC1C  VALUE  (LY)  FILE 


Entry  Lumber  1 
Element  Content 


1 


Link  Element 


4 

5 


6 


7 

8 

9 


Lumber  of  Boundaries  -  liE  (  =  1  to  2) 

Lumber  of  Segments  in  First  Boundary  -  HS(1) 
(=  1  to  5) 

Lumber  of  Segments  in  Second  Eouncary  -  LS(2) 
(=  1  to  5)  (=  C  if  HE  =  1  ) 

Link  Word  to  Entry  Containing  discriminant 
vector  of  First  Segment  of  Second  Boundary 
(if  it  Exists) 


Link  to  Entry  Containing  First  (and  second, 
if  it  exists)  boundary  segment  discriminant 
value  thresholds. 


Lode  Lumber  Associated 

Node  Lumber  Associated 
Eoundary  1 

Node  Number  Associated 
Boundary  2  (Ignored  if 


kith  Excess  Region 
kith  Convex  Side  of 

With  Convex  Side  of 
LB  =  1  ) 


Remaining  LS(1)  +  NS(2)  Entries 
Element  Content 


1 


I 

I 

I 

•  | 

> 

I 

•  I 

j 

NDIM  +  1  - 


Link  Element 


NDIM  Discriminant  Coefficients 


Figure  4-15  Two-Space  Croup  Logic  Elock  Format 
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Last  Entry 


Element 


Content 


Link  Element 


Threshold  Values 


(LCTE:  End-boundary  thresholds  appear 
immediately  after  those  of  1st 
boundary,  with  no  intervening  space) 


Figure  4-15  Two-Space  Group  Logic  Elock  Format  (continued) 
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Entry  Lumber  1 
Element  Content 


1 

c. 

3 

4 


Link  Element 

Number  of  Characters  in  Lcolean  Statements 
NC  (max  132) 

Node  Number  Associated  With  True  "Side" 
Node  Number  Associated  With  False  "Side" 


Remaining  Entries  -  Number  Sufficient  to  Contain  NC  Elements 
Element  Content 


1 


NDIM+2 


Link  Element 


Characters  of  Boolean  Statement 


Figure  4-16  Boolean  Group  Logic  Block  Format 


68 


Portable  CLFARS  Piling  Structure  --  4 
THE  LOGIC  VALUE  (LV)  FILL 


Entry  Lumber  1 
Element 


Content 
Link  Element 

Lumber  of  Classes  -  I'CLAS 

Weight  Flag:  1  -  Ho  Weights, 

2  -  Weighting  Vectors, 

3  -  Weighting  Matrices, 

4  -  Quadratic  Classifier 

Link  Element  to  First  Entry  Containing  Means 

Link  Element  to  First  Entry  Containing  Weighting 

Vectors 

Link  Element  to  First  Entry  Containing  Weighting 
Matrices 

Ignore  Measurement  Flag:  C  -  Use  All, 

1  -  Ignore  Some 

Reject  Flag:  C  -  No  Reject  Boundaries,  1  -  Use 
Reject  Boundaries 

Link  Element  to  First  Entry  Containing  Reject 
Values 

Link  Element  to  First  Entry  Containing 
Determinants 


Entry  Number  2 
Element  < 


Content 
Link  Element 


NDIK+1  - 
NDIM+2 


Measurements  to  be  Ignored  Flags 

=  1  Use  Corresponding  Measurement 
=  0  Ignore  Corresponding  Measurement 


Number  of  Mieasur ements  Used 


Figure  4-17  Nearest  Mean  Vector  Logic  Elock  Format 
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Next  Group  of  Entries  -  Number  sufficient  to  contain  NCLAG+1 

Elements 


Element 


Content 


Link  Element 


Node  Number  Associated  w/rejects 
Node  Number  Associated  w/first  class 


Mode  Number  Associated  w/last  class 


Next  Group  of  Entries  -  Number  sufficient  to  contain 

NCLAS  elements 


Element 


Content 


Link  Element 


NCLAS  reject  boundary  distance  values 
(square  of  value  entered  by  user) 


Next  NCLAS  Entries  -  One  entry  per  class 


Element 


Content 


Link  Element 


NDIM  Mean  Components 


NCIM  +  1  - 


Figure  4-17  Nearest  Mean  Vector  Logic  Elock  Format  (continued) 
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Next  f.CLnS  Entries  -  Cne  entry  per  class 
Element  Content 


1 


Link  Element 


NDIK  +  1 


i 

i 

i 


> 


NDIM  Weighting  Components  (variance  vector) 


Next  t.'CLAS*  (  ( NBIM/2 )+ 1  )  Entries;  (NCIh/2)+1  entries  per  class 
Element  Content 

1  Link  Element 


C.  - 

l 

i 

I 

•  I 

.  >  NDIM# (MCIM+1 )/2  packed  weighting  matrix 

.  I  components  (inverse  of  covariance  matrix) 

I 

NDIM  +  1 

Remaining  Entries  -  Number  sufficient  to  contain  KCLAS  elements 
Element  Content 


1  Link  Element 


CL 


L 


» 

I 

I 

I 


> 


I 

I 

I 

I 


NCLAS  determinants  of  the  covariance  matrix  of 
each  class 


Figure  4-17  Nearest  Fean  Vector  Logic  Block  Format  (continued) 
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Portable  CLEARS  Filing  Structure  --  4 
THE  LOGIC  VALUE  (LV)  FILE 


Second  cf  Three  Entries 
Element  Content 

1  Link  Element 


c 


tiDIk  +  1 


\ 

>  Coefficients  of  Fisher  Eirection 

/ 

\. 


Third  of  Three  Entries 
Element  Content 


1  Link  Element 


\ 

.  >  Coefficients  of  line  perpendicular  to  Fisher 

/  Direction 

KDIM  +  1  - 


Figure  4-18  Pairwise  Logic  Elock  Format  (continued) 
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Portable  CLPARS  Pili ng  Structure  --  4 
THE  LOGIC  VALLE  (LV)  FILE 


Entry  t. umber 

1 

Element 

Content 

1 

Link  Element 

2 

Humber  of  boundaries  -  HE  (=1) 

3 

Number  of  Segments  in  Eoundary  -  NS  (=  1  to  5) 

4 

UN USEE 

5 

UNUSED 

6 

Link  to  Entry  containing  boundary  segment 
discriminant  value  thresholds. 

7 

Index  to  node-number-asscciated-with-classes 
-in-the-excess-reg ion  entry  (i.e.,  the  index 
plus  one  points  to  node  associated  with  the 
Excess  Region) 

r 

c 

Index  to  node-number-asscciated-with-clesses 
-in-the-convex-reg ion  entry  (i.e.,  the  index 
plus  one  points  to  node  associated  with  the 
Convex  Region) 

9 

UNUSED 

Remaining  NS 

Entries 

Element 

Content 

1 

Link  Element 

2 

1 

1 

1 

•  1 

> 

j 

NDIM  Discriminant  Coefficients 

NDIM  +  1 

Figure 

4-18a  Optimal  Discriminant  Logic  Elock  Fermat 
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Pcrtsble  CL PAR 2  Filing  Structure  --  4 
1HE  LOGIC  VALUE  (LV)  FILE 


i 

> 

i 

i 


Last  Entry 
Element 


10 


Content 


Link  Element 


Threshold  Values 


Figure  4-1 8a  Optimal  Discriminant  Logic 
Block  Format  (continued) 


Portable  CL FA h 3  Filing  Structure  --  4 
THE  LOGIC  VALLE  (LV)  FILE 


Entry  Lumber  1 
Element  Content 


1  Link  Element 

2  Humber  of  classes  -  C LAS 

3  Flag:  1  -  create  node  of  overlapped  vectors 

C  -  reject  overlapped  vectors 

4  Link  element  to  first  entry  containing  link 

elements  to  sub-blocks  for  each  class 

Next  Group  of  Entries  -  Number  sufficient  to  contain 

NCLAS+2  elements 


Element 


Content 


1  Link  element 


\  NCLAS+2  list  of  node  numbers  associated 

>  with  each  of  WCLAS  classes,  the  reject 
/  node  and  the  overlap  node 


Next  Group  of  Entries  -  Number  sufficient  to  contain 

2*NCLAS+1  elements 

Element  Content 


1  Link  element 

2  Link  element  to  the  last  entry  of  the 
preceding  group  of  entries 

(which  contain  the  node  numbers) 

3  !  Link  element  to  the  first  entry  of  the 
I  sub-block  for  the  first  class 

I 

I 

4  |  Link  element  to  the  last  entry  of  the 
!  sub-block  for  the  first  class 


Figure  4-15  Closed  Decision  Eoundary  Logic  Elock  Format 
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Portable  CLPARS  Filing  Structure  —  4 
THE  LOGIC  VALUE  (LV)  FILE 


Entry  1. umber 

i 

i 

Element 

Content 

1 

Link  Element 

2 

Sub-block  type  =  1 

3 

> 

i 

•  1 

1 

•  1 

I 

1 

I 

NDIM +2 

NDIM  Threshold 

Type  Flags:  C  =  user  defined 

1-20C  =  percentage  of 
data  range  ( ICO 
is  the  default) 

Entry  Humber 

2 

El ement 

Content 

1 

Link  Element 

[ 

2 

3  - 

) 

1 

Easis  vector  type: 

1 -coord inate  ,  2-cverall 
eigenvectors,  3-specific 
class  eigenvectors 

1 

r 

I 

•  1 

.  > 
l 

•  1 

NDIM  low  threshold 

values 

1 

i 

J 

NDIM+2  - 

Entry  Number 

3 

j 

Element 

Content 

t 

1 

Link  Element 

i 

t 

1 

2 

i 

i 

i 

•  i 

> 

NDIM  high  threshold 

values 

1 

| 

i 

I 

NDIM+1  - 


Figure  4-20  Hyperrectangular  Sub-block  Format 

'  i 
i ... 
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Portable  CLEARS  riling  structure  --  4 
THE  LOGIC  \ALUE  (LV)  FILE 


f.'ext  LEIN  Entries  (not  used  if  coordinate  basis  vectors) 
Element  Content 


Figure  4-20  Hyperrectanul ar  Sub-block  Format  (continued) 
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Portable  CLFARS  Filing  Structure  --  4 
THE  LCCIC  VALUE  (LV)  FILE 


Entry  Lumber  1 
Element  Content 


1  Link  Element 

2  Sub-block  Type  (=2) 

3  Center  Vector  Type:  1-mean  of  class, 

2 -midrange  of  class,  3-user  defined 

4  hadius  Type:  C  =  user  defined 

1-2CC  =  percentage  of  data  range 
(IOC  is  the  default) 

5  Radius  (squared)  of  hypersphere 


Entry  Lumber  2 
Element  Content 


1 


a 


I 

•  I 

> 

•  ! 
i 

NDIM  +  1  -' 


Link  Element 


NDIM  components  of  center  vector 


Figure  4-21  Hypersphere  Sub-block  Format 
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Portable  CLPAhS  Filing  Structure  --  4 
THE  LOGIC  VALUE  (LV)  FILE 


Entry  Lumber  1 
Element  Content 


1  Link  Element 

2  Sub-block  type  (=3) 

3  Center  vector  type 

(see  hypersphere  sub-block  for  code) 

4  " C"  value  type  (see  hypersphere  sub-block 

radius  type  for  code) 

5  "C"  value  (corresponds  to  radius 

in  hypersphere) 

6  Axis  Type:  C  =  user-defined;  1-20C  =  2  of 
default  axis  lengths  (100  is  the  default) 


Entry  Lumber  2 
Element  Content 


1 


Link  Element 


MCI' 


NDIM  components  of  center  vector 


Figure  4-22  Hyperellipsoid  Sub-block  Format 
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Portable  CLPARS  Filing  Structure  --  A 
THE  LOGIC  VALUE  (LV)  FILE 


Entry  Number  3 
Element  Content 


1 


NDIM  +  1 


Link  Element 


NDIM  axis  lengths 


Remaining  NDIM  Entries 
Element  Content 


1 


Link  Element 


C.  — 

! 

i 

•  i 

.  >  NDIM  components  of  row  of  weighting  matrix 

I 

•  1 
I 

NDIM+1  - 


Figure  4-22  Hyperellipsoid  Sub-block  Format  (continued) 
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Portable  CLPARS  Filing  Structure  --  4 
THE  LOGIC  VALUE  (LV)  FILE 


Entry  Lumber  1 
Element  Content 


1  Link  Element 

2  Lumber  of  characters  in  Loolean  Statement  - 

HC  (max  132) 

Entry  Lumber  (in  LI  file)  for  first 
(if  more  than  1)  logic  node  to  use  this 
reject  statement 

Remaining  Entries  -  Lumber  sufficient  to  contain  LC  elements 
Element  Content 


1 


Link  Element 


L'LIM+2  - 


Characters  of  Eoolean  Statement 


Figure  4-23  Independent  Reject  Strategy  Block  Format 


Portable  CLPAhS  Filing  Structure 
THE  LOGIC  VALUE  (LV)  FILE 


1 


1 


thru  > 

I 

I 


-  4 


Entry  Number  1 

Element  Content 


Link  element 


Number  o 

f  classes 

(NC) 

K  -  number  of  near 

est  n 

eig 

hbo 

rs  to  be 

used 

in  evalua 

tion 

Ignored 

measuremen 

ts  fl 

(  =  1 

means 

there  ar 

e  measurem 

ents 

to 

be 

ignored ) 

Link  to 

Ignored  me 

asur emen 

ts 

vector 

Entry  Number  2 
Element  Content 


Link  element 


Tree  name  of  reference  patterns 


Entry  Number  3 
Element  Content 


1 


Link  element 


MDIM+1  - 
NDIM+2 


Measurements  to  be  Ignored  Vector 

=  1  Use  Corresponding  Measurement 
=  0  Ignore  Corresponding  Measurement 


Number  of  Measurements  Used 


Figure  4-24  Nearest  Neighbor  Logic  Elock  Format 


Fortable  CLPAF.S  Filins  Structure  —  a 
THE  I  CCIC  VALUE  (LV )  FILE 


Remaining  Entries  -  Lumber  Sufficient  to  Contain  LC  +  1  Elements 
Element  Content 


1  Link  element 

2  -  Lode  Lumber  Associated  w/first  class 

I 

•  !  • 

> 

« 

•  i 

!  Lode  Lumber  Associated  w/last  class 

LC+2  -  Lode  Lumber  Associated  w/rejects 


Figure  4-24  Nearest  Neighbor  Logic  Elock  Format  (continued) 


Fcrtatle  CLPARS  Filing  Structure  --  4 
THE  LCCIC  LIST  (LL)  FILE 

4.E  THE  LOGIC  LIST  (LL)  FILE 

The  Logic  List  File  is  a  list  of  the  logic  trees  that  exist  ir. 
a  user's  directory.  It  has  a  two  element  header  that  contains  the 
number  of  entries  (logics)  in  the  file,  anc  an  alphabetic  list 
pointer.  Each  logic  corresponds  to  an  entry.  An  entry  contains 
the  two  File  Codes  (FCLs)  representing  the  files  that  make  up  a 
logic  tree,  space  for  an  £  character  logic  name,  the  dimension  of 
the  tree,  the  tree  and  class  name  pair,  an  incomplete  logic  flag, 
and  an  alphabetic  list  pointer.  See  Figure  4-25. 

When  a  new  logic  is  added,  its  entry  is  placed  at  the  bottom 
of  the  LL  file.  When  a  logic  is  deleted,  its  entry  is  replaced  by 
the  last  entry  in  LL  and  the  count  of  the  number  of  entries  is 
decremented  by  1. 

The  alphabetic  list  pointer,  here,  has  the  same  function  as 
the  alphabetic  list  pointer  found  in  the  Tree  List  (TL)  file. 

4.5  THE  SAVED  VECTORS  (SV)  FILE 

The  SV  file  is  a  list  of  stored  projection  vectors  that  can  be 
accessed  by  name  using  an  arbitrary  vector  projection  operation 
(S1ARBV,  S2ARBV,  L2AREV) .  The  header  of  the  SV  contains  the  number 
of  vectors  (see  Figure  4-26).  Information  on  each  vector  is  stored 
in  an  entry.  Vector  names  are  one  to  eight  characters  ir.  length, 
start  with  a  letter,  and  are  stored  at  the  beginning  of  an  entry 
followed  by  the  dimension  and  the  vector  itself.  The  length  of  an 
entry  is  the  maximum  vector  length  allowed  for  normal  CLPARS 
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Portable  CLFARS  Filing  Structure  --  4 
Ti:E  LLCIC  LIST  (LL)  FILE 


Element 


1 

Lumber  cl  Entries 

Header 

2 

Alphabetic  List  Pointer 

File  Cede  (ICE)  for  LI  File 

4 

File  Code  (  FCE )  for  LV  File 

5-1  2 

Logic  Lame 

Entry  1 

13 

KEIH  of  Lesigr  Set 

14 

Alphabetic  List  Fointer 

15 

t  hi  r  u 

Treename,  classname 

26 

of  design  set 

27 

Incomplete  Logic  Flag 

• 

• 

3+25 (L- 1  ) 

FCE  for  LI 

FCE  for  LV 

Logic  Name 

Entry  k 

NDIM  of  Eesign  Set 

Alphabetic  List  Fointer 

Treename,  classname 
of  design  set 

2+25k 

Incomplete  Logic  Flag 

Figure  4-25  The  Logic  List  File 
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Portable  CLPARS  Filing  Structure  --  4 
THE  SAVE l  VECTCHS  (SV)  PILE 


Element 


1 

2 

Number  of 

Elank 

Vectors  ! 

1 

1 

1 

3 

Name  of 

1 

1 

thru 

1 

1 

1C 

Vector  1 

1 

1 

1 

1  1 

Dimension 

of  Vector  1  ! 

1 

12 

V 

Entry  1 

E 

1 

1 

thru 

C 

1 

1 

T 

1 

1 

61 

C 

1 

1 

R  ! 

I 

1 

1  ! 

i 

Figure  4-26  The  Saved  Vector  File 
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Portable  CLFARS  Filins  Structure  — 
THE  SAVE D  VECTORS  (SI)  FIL 

operation,  which  has  been  chosen  to  to  be  50  for  the  FDP-1 1  systems 
under  F.SX-tIM.  lienee,  vectors  in  excess  rr.e asur err.ent  mode  may  ret 
be  stored  in  SV. 

'rthen  a  vector  is  deleted  from  the  SV  file,  the  last  entry  is 
moved  up  so  that  no  "holes"  appear  in  this  file. 

The  command  VECTOR  is  used  to  manipulate  the  SV  file.  VECTOR 
has  five  options: 

1.  Delete  a  saved  vector. 

2.  Make  a  line  printer  listing  of  all  saved  vectors 
including  name,  length  and  the  components  of  the 
vector . 

3.  Display  at  the  screen  the  information  in  2. 

4.  Display  at  the  screen  one  named  vector. 

5.  Save  a  user-supplied  vector  or  the  projection 
vector(s)  used  in  a  one  or  two  space  projection . 
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Portable  CLFARS  Filing  structure  --  t 
THE  HAVE L  TRAl.SFCRKATICi.  KATE IX  (SK)  FILE 

1C  THE  LAVED  TRAl.SFCRMATICi;  MATRIX  (SK,  FILE 

Under  CLPARS,  it  is  possible  tc  save  a  measurement 
transformation  for  use  on  other  data  sets  (see  the  KEAS/.FRK 
command).  This  option  is  useful  for  the  following  reason.  If  a 
logic  is  cesigr.ed  on  a  transformed  tree,  and  if  a  test  cate  set  is 
run  through  that  logic,  the  test  data  set  shculc  be  first 
transformed  in  the  same  way  as  the  design  set.  When  the 
transformation  information  is  stored  away  it  can  be  easily  "pulled 
out"  and  used  on  the  test  data  set. 

The  transformation  information  is  saved  in  the  Saved 
Transf crmation  Matrix  (SK)  File.  After  such  commands  as  EIGHXFRK 
or  tiORKXFRX  have  completed  their  transformation,  the  programs  will 
ask  the  user  if  (s) he  wishes  to  save  the  transformation  matrix. 
(The  EIGNXFRM  transformation  is  saved  as  an  (I.'DIK)x(k)  matrix, 
where  * k*  is  the  number  of  eigenvalues  chosen  by  the  user;  the 
XOEKXFRK  transformation  is  saved  as  an  (NDIN)xl  matrix  or  vector). 
If  the  user  answers  yes,  these  routines  will  save  the  matrix  in  the 
SM  file.  The  user  can  then  use  the  saved  matrix  to  transform 
another  data  set.  The  command  that  will  accomplish  this  is  called 
MATXFRK.  It  will  prompt  the  user  for  the  name  of  a  saved  matrix 
and  then  transform  the  current  data  set  using  the  matrix  (assuming 
that  there  is  dimensional  compatibility).  The  name  of  a  matrix 
must  be  from  one  to  eight  characters  in  length,  the  first  being 
alphabetic  and  the  rest  alphanumeric. 


SC 


Forcible  CLPARS  riling  Structure 
SAVED  Tn/.JICFCF.KATICI;  KATE IX  (Sh) 


FIL: 


Cr.e  acciticr.al  command  ,  MATRIX,  is  r.e- cc-ssary  for 


maintenance  cl'  the 


file. 


MATRIX  has  the  following  options : 


a.  Delete  a  savec  ratrix; 

b.  Make  a  line  printer  listing  of  the  name,  type, 
dimension,  and  entries  cf  a  saved  matrix; 

c.  Display  at  the  screen  the  name  type,  dimension, 
and  entries  of  a  saved  matrix; 

d.  Display  at  the  screen  the  names,  types,  and 
dimensions  cf  all  saved  matrices; 

e.  Save  a  user  supplied  matrix. 


when  a  matrix  is  deleted  ,  entry  spaces  are  left  in  the  SK 
file.  In  this  case,  element  2  of  the  SK  file  header  will  point  to 
the  first  free  entry  and  the  rest  of  the  free  entry  areas  will  be 
linked.  The  last  free  entry  area  will  always  occur  after  the  last 
filled  entry,  anc  is  pointed  to  by  element  2  cf  the  SK  file  header. 
The  structure  of  the  header  of  the  SM  file  is  pictured  in  Figure 
4-27.  KAXKTR  stands  for  the  maximum  number  of  saved  matrices  the 
user  may  have.  KAXMTR  set  equal  to  1C  should  be  more  than 
sui f icient . 


An  entry  in  the  SM  file  (Figure  4-28)  will  be  the  length  cf 
the  maximum  feature  vector  allowed  in  CLPARS,  without  going  into 
excess  measurement  mode  (which  is  5C  for  the  FDP-11/7C  under 
RSX-1 1M)  plus  one  to  allow  for  a  link  pointer.  For  RCRNXFRK,  one 
entry  will  suffice  to  store  the  (NDIW)xl  transformation  matrix. 
For  EIGL'XFRK,  the  transformation  matrix  will  be  stored  in  as  many 


entries  as  necessary 


Fortable  CLPARS  Filing  Structure  --  4 
THE  SAVES  TRANSFORMATION  MATRIX  (SM)  FILE 


Element 

1 

Number  cf  Saved  Fatrices 

2 

Pointer  to  the  Head  cf  the 

Entry  Free  List 

3 

Pointer  to  the  End  of  the 

Entry  Free  List 

4 

Number  of  Vectors  in  File 

5 

through 

12 

Descrip¬ 
tion  of  13 

Matrix  "1" 

14 

Name  of  Saved  Matrix  "1" 

Type  * 

NDIM 

15 

Entry  //  of  start  of  Matrix  ** 

• 

• 

• 

'ascrip¬ 
tion  of 

Matrix  MAXMTR 

Name  of  Saved  Matrix  "MAXMTR" 

Type 

NDIM 

4  +  ( 1 1 *MAXMTR ) 

Entry  No.  of  Beginning  of  Matrix 

*  NORMXFRK  =  -1 

EIGNXFRM  =  R,  where  R  is  the  no. 

of  eigenvalues  used 

**  0  implies  not  in  use 


Figure  4-27  The  Saved  Transformation 
Matrix  File  Header 
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Portable  CLPAP.S  Filing  Structure  --  4 
THE  SAYEL  T  R  A  LSF  CRM  AT  I  O':  MATRIX  (2K)  FILE 


El  ement 


thru 


iiCIM  +  1 


*  '0  implies  last  vector  (row)  of  matrix 


Figure  4-28  The  Saved  Transformation 
Matrix  File  Entry 


sectic:;  5 


DISPLAYS 


5.C  IiiTRCDUCTICi: 

There  are  six  types  of  displays  that  CLEARS  car.  produce: 
two-space  cluster  plots,  two-space  scatter  plots,  rank  order 
displays,  confusion  matrices,  one-space  macro  plots,  and  one-space 
micro  plots.  Since  the  information  to  create  each  of  these  types 
of  displays  is  so  different,  the  structure  of  the  display  files 
will  be  discussed  individually  by  type  of  display.  However,  each 
type  uses  (at  least)  two  files:  the  Display  Information  (DI)  file 
and  the  Display  Value  (DV)  file.  The  DI  file  will  contain 
necessary  controlling  information  and  pointers  into  the  DV  file, 
and  the  DV  file  will  contain  values  to  be  displayed.  In  general, 
the  values  to  be  displayed  are  saved  so  that  the  process  of 
redisplay  (that  is,  recreating  the  last  display  on  the  terminal)  is 
a  simple  one,  and  display  manipulations  (e.g.,  elimination  or 
addition  of  a  class  on  a  two-space  display)  does  not  require  a 
complete  regeneration  of  the  display. 
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L i £ p i a y s  --  5 
1 1. IRC  DEC 71  Cl, 

The  first  element  ir.  the  LI  file  will  always  be  a  display  ccce 
as  follows: 

0  =  not  set 

1  =  two-space  cluster 

2  =  two-space  scatter 

2  -  rank  order 

4  =  confusion  matrix 

5  =  on e-space  macro 

6  =  one-space  micro 

5.1  T’-iC -SPACE  DISPLAYS  (SCATTER  AND  CLUSTER) 

A  two-space  scatter  plot  is  a  two-dimensional  representation 
cf  an  n-space  vector,  with  each  vector  located  at  its  "natural" 
projection  point  on  the  screen. 

A  two-space  cluster  plot  is  a  two-dimensional  representation 
of  an  n-space  vector,  with  each  vector  "forced"  into  a  location 
within  a  grid.  If  one  or  mere  vectors  from  a  single  data  class 
fall  within  the  same  grid  location,  the  display  symbol  for  that 
class  is  presented.  If  vectors  from  two  or  more  data  classes  fall 
within  a  single  grid  location,  an  asterisk  is  displayed. 

The  actual  presentation  of  the  two-space  cluster  display  is 
generally  faster  than  the  two-space  scatter  display,  especially  for 
a  large  data  set.  However,  since  each  character  displayed  may 
represent  one  or  more  vectors,  in  some  cases  this  display  could  be 
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Displays  --  5 

TV.' C -S FA C E  DISPLAYS  (SCATTER  ALL  CLUSTER) 


misleac  ir.g  . 


5.1.1  TLE  DISPLAY  IMF GRKATICL  (DI)  PILE  - 


The  display  file  set  up  for  twc-space  displays 
CLFARS  applications  programs  to  efficiently  create  a 
view  an  old  display,  or  change  the  scale  of  two-space 
DI  file  header  (see  Figure  5-1)  contains  the  following 


allows  the 
new  display, 
plots.  The 
information . 


o  The  display  cede  (element  1). 

o  A  code  (element  2)  for  the  type  of  coordinate  projection 
used:  LI,  L2,  SI,  S2  versions  of  ASDC-,  CKCV,  EIGV,  FSliF; 

or  NLM . 

o  The  treename,  nodename  pair  (elements  3  through  Id)  that 
makes  up  the  (current)  data  set  for  which  the  twc-spsce 
plot  was  made. 

o  The  dimension  of  the  data  set  (element  15)  and  the 
number  of  lowest  nodes  in  th2t  data  set  (element  16). 

o  The  number  of  bouncaries  is  in  element  17.  There  is  a 
maximum  of  2  boundaries  on  any  one  or  two-space  plot. 

o  Elements  IS  and  IS  enable  CLPARS  programs  to  access  the 
boundary  points  (and  2-space  convex  point)  of  the  first 
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tcuTiCary  in  the  IV  file.  (The  convex  pcir.t  is  fcur:c 
ir.  the  entry  immediately  following  the  last  pcir.t  cf 
each  boundary.  The  number  cf  points  ir.  a  boundary 
(elements  1C,  IS)  does  net  induce  the  convex  point). 

c  Clements  20  and  21  provide  the  same  information  for  the 
second  boundary,  as  do  elements  1£  and  15  for  the  first 
bound  ary . 


o  Elements  22  through  25  contain  the  minimum  anc  maximum 
x,  y  values  for  the  projected  vectors. 

c  Elements  2c  through  25  contain  the  minimum  and  maximum 
values  that  are  used  to  create  the  two-space  plot. 
These  values  are  initially  the  same  as  those  in  elements 
22  through  25.  When  a  scale  change  is  mace  by  the  user, 
using  the  command  SCALZf-i  (scale  zoom),  the  screen 
coordinates  that  specify  the  new  scale  are  transformed 
into  the  coordinate  system  cf  the  projection  vectors, 
and  are  stored  as  the  current  minimum  and  maximum 
values.  Vectors  that  lie  outside  of  this  new  region  are 
not  displayed  on  the  screen. 

o  Elements  30  and  31  contain  pointers  to  the  projection 
vectors  (in  the  PROJECTION  VECTOR  file)  used. 
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LIerr.er.ts  ll  through  1C  are  used  ir.  the  logic  cr.e-space 
(LI)  ar.c  two-space  (L2)  projection  rcutir.es.  They  store 
the  r.oEfc  of  the  logic  ar.d  tr.e  r.ccc.  .-.ureter  :  or  whicr  t;.e 
projection  was  r tree. 


c  Element  Li  contains  the  total  nurr.ter  cf  vectors  ir.  the 
ccta  set.  It  is  used  ir.  determining  whether  to  produce 
a  scatter  cr  cluster  plot.  If  it  is  larger  than  5CC,  a 
cluster  plot  is  produced  .  If  it  is  ZZ C  or  less,  a 
scatter  plot  is  produced .  This  default  value  cf  5CC 
may  he  changed  by  the  user  (see  the  command  CEEFAL'LT). 


o  Elements  42  and  45  are  for  one-space  displays  only  ar.d 
are  ignored  in  the  twc-space  case. 


o  Element  43  determines  the  type  of  scaling  to  be  used  for 
a  two-space  display,  either  square  cr  rectangular. 
Square  scaling  is  the  default  and  may  be  changed  by  the 
the  user  (see  the  command  CSCALE). 


o  Element  44  is  the  zoom  flag  for  one  cr  two  space 
displays  and  when  set,  indicates  zooming  is  in  effect 
(i.e.,  the  display  scale  has  beer,  modified  to  get  a 
"closer"  lock  at  classes  found  on  the  display). 


La. 
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For  each  class  (Icv.est  node  ir.  the  cats  set)  there-  is  a 
logical  entry  ir.  the  LI  file  (see  Figure  5-2). 

All  vectors  from  s  class  will  be  stored  in  the  IV  file  in 

sequence.  Therefore,  elements  5  £r.c  6  of  the  logical  entry  for 

that  class  will  give  access  to  all  of  the  projected  vectors. 

(Element  6  actually  points  to  the  projection  of  the  mean  vector  of 
the  class.)  Element  7  indicates  whether  or  not  the  vectors  from  the 
class  should  be  displayed  or.  the  screen.  This  element  is  initially 
"or."  and  can  te  reset  by  using  the  command  SELECT.  The  display 
flag  symbol  (element  3)  appears  next  to  the  class  symbol  of 

"classes-cisplayed-and-currently  selected"  list  of  the  one  or  two 
space  display.  (Currently,  this  symbol  is  only  important  with 
displays  using  the  Fisher  discriminant  plane.  All  projection 
subroutines  (e.g.  DSPF.CJ,  LCPRCJ)  initially  make  this  symbol  a 
' blank  . '  ) 


5.1.2  71. Z  DISPLAY  VALUE  CY)  FILE  - 

The  general  structure  of  the  LV  file  for  a  data  set  with  'k' 
lowest  nodes  is  pictured  in  Figure  5-3. 

The  LY  file  header  (see  Figure  5-c)  is  just  four  elements 
long.  The  first  twc  elements  ccntain  information  for  the  purpose 
of  cross  checking  the  CV  file  with  the  Cl  file.  The  third  element 
ir.cicates  whether  cr  net  screen  coordinates  have  been  computed. 
This  flag  will  be  used  in  situations  where  vectors  must  be 
redisplayed  but  the  screen  coordinates  have  already  been  computed 
(e.g.,  the  commands  f ELECT,  f.DISFLAY).  Element  L  points  to  the 
next  available  entry  at  the  end  of  the  file. 

The  projected  vectors  from  a  data  class  are  stored  together  in 
a  block  in  the  EV  file  (Figure  5-3).  The  first  vector  in  each 
block  is  always  the  projection  of  the  mean  vector  of  the  class. 
For  structure  analysis  displays,  the  mean  vector  of  a  class  is 
stored  in  the  TI  file  and  is  projected  and  inserted  into  the  LV 
file  before  the  rest  of  the  vectors  from  that  class  are  projected 
and  stored.  For  logic  design  displays,  the  projected  mean  vector 
may  have  to  be  computed  after  the  rest  of  the  vectors  from,  a  class 
(cr  part  of  a  class)  are  projected. 


In  either  situation,  the  mean  vectors  will  not  be  initially 
displayed  on  the  terminal  screen.  If  users  wish  to  see  the 
projected  mean  vectors  (for  the  classes  that  are  being  displayed) 
superimposed  on  the  screen,  they  should  invoke  the  command  FRCJKL. 


1C2 


Display  Code 


0 1  ?/. ?. D  Option  Huxber 


Screen  Coordinate  FT  ao 


:iext  Available  Entry 


0= screen  coord 
not  cc.nputec 

1 = screen  coord 
computed 


Figure  5-4  The  CV  File  Header  for  One-Space 
and  Two-Space  Displays 


Displays  -- 
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PECJMN  will  display  the  mean  vectors  on  the  existing  display  with 
small  rectangles  around  the  appropriate  class  symbol 

A  D  V  file  logical  entry  (see  Figure  5-5)  contains  all  the 
necessary  information  about  a  projected  vector  or  a  boundary  point. 
The  ID  of  a  mean  vector  is  a  negative  one  (-1)  ana  the  ID  of  a 
boundary  point  is  zero  (C).  Screen  coordinates  are  discussed  in 
Section  5  .  1 .  A' . 

When  storing  boundary  information,  the  actual  boundary  points 
will  be  stored  first  (there  can  be  at  most  six  such  points), 
followed  by  the  point  on  the  "convex  side"  of  the  boundary.  The  x 
and  y  coordinates  of  the  boundary  points  will  be  computed  by 
DRAw EDDY  as  they  are  entered  by  the  user. 

5.1.3  ThE  PROJECTION  VECTOR  (PV)  FILE  - 

There  is  one  other  file  that  will  be  necessary  for  the 
efficient  display  of  two  space  plots.  This  is  the  Projection 
Vector  (PV)  File.  It  contains  the  n-d imensicnal  vectors  on  which 
the  data  set  is  projected.  Each  entry  is  of  length  NDIN  and 
contains  a  projection  vector.  In  addition,  eigenvectors  (and 
eigenvalues)  that  have  not  been  chosen  by  the  user,  are  saved  in 
this  file.  If  the  user  wishes  to  reproject  on  a  different  set  of 
eigenvectors,  for  example,  they  are  immediately  available  for  use. 
The  structure  of  the  FV  file  is  pictured  in  Figure  5-6.  Notice 
that  the  vectors  actually  used  in  the  projection  are  pointed  to  in 
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elements  17  End  1  £  cf  this  file.  These  vectors  are  also  referenced 
in  elements  30  end  31  cf  the  LI  file  header.  For  coordinate 
projections,  the  FV  file  contains  an  iac-ntity  matrix.  For  the  ASIC 
and  FEliP  commands  this  file  contains  only  one  or  two  vectors. 

FCRTRAIi  GLPARS  allows  users  to  delete  specific  ir.easurments  in 
most  structure  analysis  or  logic  design  projections.  Any 
measurements  that  are  deleted  from  such  a  projection  are  kept  track 
cf  in  the  FV  file  as  follows.  The  number  of  measurements  used  in 
the  computation  is  saved  in  element  15.  The  first  entry  cf  the  FV 
file  contains  a  measurement  vector  (cf  length  fiDIK)  which  is  a 
vector  of  zeroes  and  ones.  A  one  occurs  if  the  measurement  is  used 
in  the  computation;  otherwise,  a  zero  is  placed  in  that 
coordinate.  For  the  eigenvalue  options,  the  number  of  eigenvalues 
equals  the  number  of  measurements  used. 

The  projection  vectors  stored  ir.  the  FV  file  also  have  length 
NDIM.  This  results  from  placing  zeroes  in  the  deleted  coordinate 
positions  of  the  projection  vectors. 
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5  -  1 .  t  Screen  Coordinates  - 

The  set  cf  x  anc  y  "coordinates" f  found  in  the  TV  file  logical 
entry  (see  Figure  5-5)  for  each  vector,  is  the  projection  point  of 
the  vector  onto  the  plane  cf  the  projection  vectors.  This  set  cf 
coordinates  remains  fixed  as  long  as  the  projection  vectors  remain 
fixed.  The  set  cf  x  ar.a  y  "screen  coordinates"  is  the  system 
dependent  screen  position  of  the  point.  The  "screen  coordinates" 
depend  on  which  calculated  two  space  option  is  used,  cluster  or 
scatter . 

A  hypothetical  screen  for  CLPAF.S  with  a  rectangular  two-space 
display  area  is  pictured  in  Figure  5-7.  It  is  assumed  that: 

a.  The  coordinates  start  at  (0,0  ir.  the  lower  left 
corner  of  the  screen. 

b.  Each  character  is  represented  in  a  rectangle  Vc 
units  by  He  units  and  is  displayed  by  specifying 
coordinates  for  its  lower  left  corner. 


1 C  9 


0  ,  u )  as 

'.is  =  number  of  display  units  in  screen  width 

Hs  =  number  of  display  units  in  screen  height 

l.’d  =  number  of  display  units  in  display  width  =  c-a 

hd  =  number  of  display  units  in  display  height  =  c-b 

fiC  -  number  of  display  units  in  character  width 

He  =  number  of  display  units  in  character  height 

(a,b),  (cfb)f  (c,d),  and  (a, a)  arc  the  screen 
coordinates  of  the  display  rectangle. 


Figure  5-7  A  hypothetical  screen 
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For  a  scatter  plot,  the 


vector  are  given  by 


screen  coordinates  (Xs,  Ys }  of 


Xs 


X  -  Xr.in 

-  (hd  -  FV.'c)  +  a  +  '.vc  Xirin  <=  X  <=  Xrr.ax 

FAX 


X  <  Xr.in  or  X  >  Xr;.ax 


Ys 


Y  -  Y  rr.  i  n 

-  (Hd  -  2iic)  +  b  +  He  Yrr.in  <=  Y  <=  Yrr.ax 

Yr.ax  -  Yir.in 

G  Y  <  Yir.ir.  cr  Y  >  Yr.ax 


where  x,y  are  the  pi  ;jected  values  of  the  vector  and 

FAX  =  maximum  ( Xmax  -  Xroin ,  Ymsx  -  Ymin) 

when  ’square'  scaling  is  used  and 

MAX  =  (Xmax  -  Xrrin)  for  Xs 
FAX  =  (Yrr.ax  -  Yrr.in)  for  Ys 

when  'rectangular'  scaling  is  used. 

The  "current  values"  of  Xrr.in,  Xrr.ax  ,  Yr.in ,  Ymax  (found  in  the 
El  file  header)  are  used  and  Xs ,  Ys  are  interpreted  as  integer 
values  for  display.  The  calculation  of  (Xs,  Ys)  is  set  up  so  a 
display  point  never  falls  on  the  display  border. 
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Fcr  cluster  plots,  a  grid  r.ust  be  super  irr.pc-sec  cr.  the  LLFAFS 
cispiay  wince.-;  (see  Figure  5-0.  '..e  new  interpret  the  screen 
coordinates  (Xs,  Ys)  cf  a  vecicr  tc  be  the  coll  ir.  which  the 
projected  vector  (x,y)  lies. 

Xs  and  Ys  are  given  by  the  formulas: 


-  xmn 


CD  +  1 


Xn.in  <=  X  <  Xir.ax 


X  =  X  rr.  a  x 


X  <  Xrnin  cr  X  >  Xr.ax 


Ys  = 


Yrr.sx  -  Y 


b.AX 


(K) 


Yrr.in  <  Y  <=  Yrr.ax 


Y  =  Yrr.in 


Y  <  Yrr.in  cr  Y  >  Yrcsx 


Again,  Xs ,  Ys  are  interpreted  as  integer  values.  Xote,  fcr 
both  cluster  and  scatter  displays,  if  Xs  =  0  cr  Ys  =  G,  it  means 
that  the  point  ( Xs ,  Ys)  fell  outside  of  the  region  to  be  displayed. 
Such  points  are  not  displayed. 
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Seme  auciticnal  considerations  ccr.cerr.ir."  screen  cccrc ir.ate-s 
are  as  fellows: 

c  The  constants  ’..s  ,  i.s  ,  V.d  ,  He,  kc  ,  l.c  ,  a,  fc,  c  , 
c,  ,  and  !.  are  all  system  dependent  er.c  are 
deterr.ir.ee  by  experimentation  with  the 
particular  terminal.  Ir.  order  to  make  much  of 
the  code  that  utilizes  these  constants  system 
i  r.c  eper.d  ent ,  we  cid  the  following: 

cc  The  constants  reside  ir.  an  CLPAKS  file 
that  car.  be  easily  updated  by  "systems" 
personnel . 

cc  Cne  of  the  functions  that  the  HELCLP 
command  provides  is  to  request  the 
terminal  type  from  the  user.  HELCLP 
will  then  place  the  correct  constants 
into  the  CM  file  (see  Section  4.1)  for 
use  by  the  display  programs.  This  way 
the  same  CLPAKS  programs  can  put  up 
displays  on  different  size  terminal 
screens . 

Appendix  E  shows  an  example  file  containing  screen  coordinates 
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The  'type  cf  scaling'  flag  and  'zoom'  flag  (elements  S3  ar.c  s* 
of  the  two-space  display  information  file  header)  centre!  the 
scaling  found  cr.  the  cwc-space  display. 


Initially,  all  sue -space  projections  have  'square'  scaling. 
This  means  that  the  value  of  the  measurement  units  on  both,  the  x 
and  y  axes  are  equal.  When  scale  "zooming"  (obtaining  a  clcse-up 
view  of  a  subsection  cf  the  original  display)  cr  a  scale  change 
cccurs,  the  scaling  becomes  'rectangular',  that  is,  the  value  cf 
the  measurement  units  on  the  x  and  y  axes  are  nc  longer  equal. 


5.1.6  Original  Anc  Current  Kin-Max  Coordinates  - 

The  'original'  minimum  and  maximum  coordinates  are  ebtainee 
during  initial  data  projection  computations  (Global  Scale).  Since 
the  initial  twc-space  scaling  is  'square',  the  'current' 
coordinates  are  obtained  by  using  the  maximum  range  of  the 
'original'  min-max  coordinates.  Thus,  the  current  min-max 
coordinates  are  readjusted  original  coordinates.  If  the  CSCALE 
(change  scale)  command  is  used  immediately  after  a  two-space  data 
projection,  the  display  would  use  'rectangular'  scaling  with  the 
current  min-max  coordinates  equal  to  the  original  min-max 
coordinates.  If  the  SCALZM  (scale  zoom)  command  is  used  to  obtain 
a  display  subsection,  the  current  min-max  coordinates  reflect  the 


exact  subsection  requested  by  the  user  (zoom  scale).  If  the  CSCALE 
command  is  used  after  SCALZM,  the  maximum  range  of  the  current 
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mir.-max  ccorcinates  is  used  tc  readjust  these  cocrcir.ates  sc  that 
the  type  of  scaling  is  'square',  '..here  returning  the  display  tack 
tc  its  global  scale  ( SCALP.  ET  command),  the  'square'  scaling  range 
is  usea  again  for  the  current  rain-max  ccorcinates.  See  Figure  5-CA 
fer  a  table  summary  of  the  original  ar.d  current  min.-max  cocrcir.ate 
states. 

5.2  CUE-SPACE  DISPLAYS  (MICRO  ADD  MACRC) 

CLEARS  can  produce  two  types  of  one  space  displays.  They  are 
referred  to  as  "micro"  and  "macro"  displays.  The  one-space  micro 
display  is  a  view  of  selected  data  class  histograms  presented  in 
symbolic  format.  Using  the  II.'TEIiS IF Y  command,  selected  class 
histograms  can  appear  as  bar  graphs.  The  cr.e-space  macro  display 
is  a  view  of  selected  data  classes  in  a  "stack  histogram"  format. 
Examples  cf  these  types  of  displays  appear  in  the  CLPAES  VI  User's 
Manual . 


The  display  files  for  one-space  displays  are  very  similar  tc 
those  for  two  space  displays.  The  El  file  header,  shewn  in  Figure 
5-1,  is  identical  to  the  two  space  case.  Information  like  Ymin, 
Yrr.ax ,  number  of  point"  in  a  boundary,  that  are  only  used  in  two 
space  displays,  are  ignored.  Element  42  contains  the  number  of 
bins  used  in  the  display;  element  43  is  used  tc  determine  the 
vertical  scale  for  micro  plots;  element  45  shews  whether  cr  not 
any  of  the  classes  for  a  micrc-view  display  have  been  "intensified" 
(micro-plots  only). 
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The  El  file  logical  entry  one  space  displays  is  shewn  ir. 
Figure  5-S.  The  intensity  flag  is  used  tc  determine  whether 
histograms  should  be  crawr.  on  one  space  micro  cisplays.  Fcr  each 
class  ir.  a  data  set  or  logic  node,  there  will  be  a  logical  entry  in 
the  El  file.  The  histogram  information  fcr  each  class  is  stored  ir. 
the  scratch  1  (SI)  file  and  can  be  accesseo  via  the  bin  count 
pointer  of  the  1-space  logical  entry. 

The  LV  file  fcr  one  space  displays  has  the  same  header  as  fcr 
two  space  displays  (see  Figure  5-^),  and  a  logical  entry ,  one  fcr 
each,  projected  vector  cr  boundary  point,  as  pictured  in  Figure 
5-1C.  In  order  to  define  the  "screen  coordinate"  of  a  vector  in  a 
one  space  display,  let  LE  be  the  number  cf  bins  fcr  the  display. 
Then,  l.E  is  given  by  the  equation  » 

total  it  cf  vectors 

!!E  =  min( -  ,  ME), 

(it  cf  classes)  (cne-space  bin  factor) 

where  KB  is  the  maximum  number  of  bins  allowed  on  a  one  space 
display.  The  one  space  bin  factor  has  the  default  value  of  5,  as 
in  KCCS,  but  can  be  changed  by  the  user  executing  the  command 
CEEFAULT  (this  bin  factor  is  stored  in  the  CK  file). 
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Ptr.  to  projected  vectors  in  DV 


Display  flag  ('  means  cispiay  class 
0  Keans  don’t  shew  it) 


Display  Flag  Symbol 


Intensify  flag  (1  means  intensify 

C  means  don’t  do  it) 


to  bin  counts  in  SI 


igure  5-9  The  DI  File  Logical  En 
for  Cne-Space  Displays 


ISplays  -- 


«ectcr  xD 


x  coordinate 


x  screen  coordinate 


0  if  a  boundary  point 
-1  if  mean  vector 


Figure  5-10  The  DV  File  Logical  Entry 
for  Cr.e-Space  Displays 
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Xscreer.  is  defined  by  the  equation 


Xscr  eer. 


X  -  Xrrin 

—  — — — —  (i iLj  +  1  if  Xm  i  r,  ■C -  X  ^  Xir.ax 
Xir.ax  -  Xrrin 

I. L  if  a  =  Xir.ax, 


C 


if  X  <  Xniin  or  X  >  Xir.ax 


where  the  current  values  of  Xir.ir.  and  Xr.sx  are  used  ,  and  Xscreer.  is 
interpreted  as  a r.  integer.  Xscreen  is  the  tin  number  in  which  the 
projected  vector  lies. 

The  FV  file  for  one  space  is  the  same  as  for  two  space  (see 
Figure  5-6),  except  that  element  18  is  ignored. 

Cne  space  displays  use  one  additional  file;  the  SI  (Scratch 
1)  file.  For  each  class  in  the  data  set  or  logic  node,  SI  will 
contain  the  number  of  vectors  (from  that  class)  in  each  bin. 
Storing  this  additional  information  will  require  less  ccmputaticns 
in  options  like  REDISFLAY  and  SELECT. 

The  SI  file  header  (see  Figure  5-11)  contains  information  that 
enables  programs  to  decide  whether  or  not  the  SI  file  contains  the 
correct  data.  The  SI  header  also  contains  the  maximum  bin  count 
(over  all  classes)  which  is  used  in  determining  the  length  of  the 
bars  in  the  one  space  macro  display.  The  length  of  a  logical  entry 
in  SI  will  be  the  maximum  number  of  bins  allowed.  There  is  cne 
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Lisplays  --  5 
Cl.E-SF  ACE  uIEPLAYE 


(MICRC  AI.D 


MACRO 


logical  entry  fcr  each  class  and  th.is 
element  9  cf  the  LI  file  entry  for  that  class.  Figure  5-12 
the  format  of  the  SI  logical  entry  for  one-s^sce  displays. 


shows 


5.2.1  Screen  Parameters  For  Cne  Space  Eisplays  - 

The  following  set  of  system  dependent  screen  parameters,  that 
will  be  accessible  to  CLPARS  in  the  way  described  in  Section 
5.1.0,  are  necessary  for  one-space  displays  (see  Figure  5-12). 


(e,f)  -  The  screen  coordinates  of  the  display  line  cf 

(g,i)  the  first  class  displayed.  (Classes  are 

displayed  from  the  bottom,  upwards). 

Es  -  The  distance  between  successive  display  lines. 

NC  -  The  number  of  classes  that  can  be  displayed  on 

the  screen  at  one  time  in  a  macro  display.  The 
coordinates  of  the  endpoints  of  the  last 
display  line  are  the  (e,  f  +  (NC  -  1)Ds)  and 
(g,  f  +  (NC  -  1  )Ds )  . 

The  heights  of  the  bars  in  the  one  space  macro  display  is 
computed  as  follows.  The  bar  representing  the  maximum  bin  count  is 
based  on  the  value  Es-6.  Ail  of  the  other  bars  are  then  scaled 
according  to  this  height.  See  the  subprogram  MACRCF  for  further 
information . 
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:c.v 


l.L. 


(2  FLAY  FILES  USED  IS  KEASl'R EKED'T  EYALUATICL  CCI 


The  Display  Information  (DI)  file  ana  the  Display  Value  (DY) 
file,  where  used  with  Measurement  Evaluation  Commands,  have  formats 
as  described  below.  The  general  scheme  is  similar  to  display 
handling  for  other  CLPARS  functional  applications  ir:  that  the  LY 


file 

contains  the  basic,  raw  data  computed  by  the 

major 

analytic 

fur.c 

tier. 

(Discriminant  Measure  or  Probability  of 

Con  f usi 

or.)  ; 

the 

L I 

file 

contains  control  information  and  the 

forma 

ztec 

or 

manipulated  subset  of  the  raw  data,  organized  for  display  to  the 
user,  as  determined  by  the  associated  subsidiary  commands. 

In  the  case  of  PRCBCCNF,  an  extra  file,  SI  (Scratch  1),  is 
used  (temporarily)  to  support  computation  of  values  which  are 
stored  in  the  CV  file. 


Formats  for  these  files  are  given  in  the  following  figures: 


Figure  5-1*1  Rank  Crder  Cl  Header 

Figure  5-15  Rank  Order  DI  Entry 

Figure  5-16  Rank  Order  DV  File 

Figure  5-17  Rank  Crder  SI  Header  (PRCBCCUF  Only) 

Figure  5  —  1 C  Rank  Crder  SI  Entries  (PRCECCI.'F  Cnly) 

Figure  5-15  Rank  Crder  SI  Example  (PRCECCHF  Cnly) 
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Figure  5-15  Rank  Order  DI  Entry 
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Figure  5-18  Rank  Order  SI  Ent 
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Figure  5-19  Example  of  Rank-order  SI  file 
offsets  and  pointers 
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5.4  CCNFUSICf*  MATRICES 

There  are  two  types  of  confusion  matrices  that  CLPARS  can 
produce;  between-group  and  wi thin-grcup .  The  between-group 
confusion  matrix  (see  Figure  5-20)  is  generated  when  designing 
logic  using  a  cne-space  or  two-space  group  logic  command, 
partitioning  the  resultant  data  projection,  and  finally  using 
CREATLCG  to  create  the  group-logic.  Since  it  might  be  desirable  to 
redisplay  the  one  or  two-space  projection  and  the  boundaries  upon 
which  the  logic  might  have  been  based,  this  type  of  confusion 
matrix  is  not  stored  in  the  display  files. 

The  within-group  confusion  matrix  (see  Figure  5-21)  is 
produced  as  a  result  of  the  design  or  application  of  a  complete 
within-group  logic  (closed  decision  boundary,  Fisher,  I, MV),  a  logic 
evaluation  on  the  design  set,  or  a  logic  evaluation  on  a  test  set. 
The  information  to  create  this  confusion  matrix  is  stored  in  the  DI 
file.  The  Cl  file  structure  for  the  within-group  confusion  matrix 
is  described  next. 
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Figure  5-20  Between-Group  Confusion  Matrix 

(not  stored  in  a  file) 
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Figure  5-21  ,V i thin-Group  Confusion  Matrix 
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The  DI  file  header  (see  Figure  5-22)  contains  information 
summarizing  the  logic  evaluation,  as  well  as  the  names  of  the 
assigned  classes,  i.e.,  those  classes  that  reside  at  the  lowest 
logic  nodes.  The  constant,  Max,  denotes  the  largest  number  of  data 
classes  that  a  logic  tree  may  have,  which  is  assumed  to  be  50. 

For  each  true  class,  i.e.,  the  data  class  being  evaluated, 
there  is  an  entry  in  the  DI  file.  It  contains  the  class  name  and 
the  information  that  appears  under  the  name  in  the  confusion  matrix 
display.  See  Figure  5-23. 

The  DV  file  is  not  used  to  create  the  confusion  matrix  display 
at  the  screen.  The  DV  file  may  be  used  at  a  later  date  to  store 
certain  logic  design  error  information  that  can  be  sent  to  the 
printer  under  the  various  line  printer  options.  However,  this  is 
presently  accomplished  by  creating  a  temporary  sequential  file  to 
store  such  information. 
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Figure  5-22  The  DI  File  Header  for 
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SECTION  6 

TERMINAL  AND  TEXT  FILE  INPUT/OUTPUT 


6 . C  INTRODUCTION 

The  following  sections  describe  the  terminal  character  I/C 
package,  the  terminal  graphics  I/C  package,  and  the  text  file  I/C 
package.  The  terminal  character  I/O  and  the  text  file  I/C  packages 
were  based  on  similar  packages  that  can  be  found  in  the  UNIX  I/C 
library.  The  graphics  I/C  package  resembles  the  FORTRAN  PLTMAP 
routines . 

6.1  CL PARS  TERMINAL  CHARACTER  INPUT/OUTPUT 

The  CLPARS  programs  use  terminal  input  and  output  character 
handling  routines.  Due  to  the  nature  of  the  task  required  of  these 
routines,  they  should  be  considered  system  dependent. 

The  terminal  input  routine  (TRMCET)  obtains  its  information  as 
a  character  string.  It  will  perform  a  translation  of  these 
characters  to  some  internal  representation,  specified  by  a  format 
control  string.  The  reason  for  having  a  terminal  input  routine 
translate  the  user  input  characters  and  not  a  FORTRAN  I/C  package, 
is  that  some  FORTRAN  I/O  packages  abort  a  program  when  the  input 
cannot  be  interpreted  properly.  This  is  totally  unacceptable  for 
the  CLPARS  system.  By  having  its  own  terminal  input  routine,  an 
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CLFARS  program  can  control  what  happens  when  it  receives  invalid 
i  r.put . 

To  be  consistent  and  not  rely  on  what  a  FCRTRA1.'  I/C  package 
can  handle,  CLEARS  programs  also  use  a  terminal  output  routine 
(TRNFUT).  This  routine  translates  the  internal  representation  of 
data  into  a  character  representation,  via  a  format  control  string. 

The  following  text  explains  in  greater  detail  what  a  format 
control  string  may  contain,  and  how  the  terminal  I/C  routines  will 
function.  Most  of  the  format  conversion  characters  coincide  with 
FORTRAN'S  conversion  characters.  The  specific  actions  taken  during 
a  conversion  process,  however,  may  be  slightly  different. 

To  be  able  to  format  terminal  output,  it  is  necessary  to  have 
complete  and  easy  control  over  the  terminal  writing  mechanism 
(i.e.,  cursor,  type  ball  and  carriage,  matrix  printer  head,  etc.). 

In  this  section,  the  writing  mechanism  will  be  known  as 
" cur  sor"  . 

To  control  the  cursor,  a  programmer  needs  to  specify  when  it 
should  move  down  a  line  (line  feed),  or  when  it  should  move  to  the 
right  (tabs,  spaces)  or  left  (backspaces,  return).  The  following 
paragraphs  specify  a  character  representation  of  the  cursor 
control,  that  will  be  used  in  the  terminal  I/O  format  control 
strings . 
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c.1.1  Special  Characters  Within  A  Format  Control  String  - 


The  provides  for  writing  tabs,  r.ew  lines,  backspaces,  line 
feeds,  anc  carriage  returns  so  that  they  are  visible  to  a 
programmer .  The  symbol  ' is  known  as  an  "escape  character", 
i.e.,  whatever  character  follows  * : *  is  in  some  way  special. 


The  previously  mentioned  special  characters  are  represented  as 
follows . 


:E[n] 


:  L 
:R 


:  T 


:  F 


newline  character,  i.e.  carriage  return  and  line  feed 
backspace  'n'  character  positions 
line  feeci  character 
carriage  return  character 

tab  character  (tab  stops  are  placed  at  eight  character 
intervals  from  beginning  of  line,  i.e.,  1,  9,  17,  25  ...) 

form  feed  character 


To  obtain  the  escape  character  in  a  string,  must  be  used. 
(Note,  due  to  FORTRAN  conventions,  the  single  quote  character 
cannot  be  "escaped".) 


Other  special  character  meanings: 

:P[n]  place  line  cursor  to  'n’th  character  position  within  the 
current  (buffer)  line. 

:X[n]  input:  skip  over  the  next  ' n ’  characters  in  the  current 

(buffer)  line 

output:  transmit  *nr  blanks  to  the  current  (buffer) 
line.  Note,  if  n  is  missing  in  either  of  the 
above,  1  is  assumed. 
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Note,  if  the  numeric  ;  r^'ment  is  missing  from  the  :E,  :P,  cr 

:X  special  characters,  a  value  of  1  is  assumed.  Also,  if  the 
numeric  argument  of  these  special  characters  is  ar.  asterisk  (*), 
the  numeric  value  for  the  character  is  to  be  founc  in  the  argument 
list  of  the  character  I/O  routine  processing  the  format  control 
list . 

Examples : 

(  In  the  following  examples,  the  symbol  '[]' 
represents  the  final  cursor  position.  ) 

if  format  =  ’HI,  HCW  ARE  YOU?’ 

HI,  HCW  ARE  YOU?[ ] 

if  format  =  ’I  AM  FINE,  THANK  YOU.:!!’ 

I  AM  FINE,  THANK  YOU. 

[] 

if  format  =  ’WATCH  THIS!  A: LB : LC : L: ED: RE ’ 

WATCH  THIS!  A 

B 

C 

E[]  D 

if  format  =  ’TEST :TTABBING:TKECKANISM : N  ’ 

TEST _ TABEING_MECHANISM .  (Note:  is  strictly  a 

[]  place  holder  for  spaces, 

i.e.,  a  space  character 
really  should  appear 
where  does) 

if  format  =  ’SPACE : X5EXAMPLE : X3WITH : X3P0SITI0NING. : P26RE : N • 
SPACE  EXAMPLE  WITH  REPOSITIONING. 
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6.1.2  TRMFUT  - 

The  calling  sequence  for  TRMFUT  is: 

CALL  TRMPUT  (format-string,  argl,  srg2,  ...) 

TRMFUT  is  a  terminal  output  subprogram.  It  formats,  converts, 
and  prints  its  arguments  to  a  user's  terminal,  under  control  of  a 
format  string.  The  format  string  will  contain  three  types  of 
objects:  plain  characters,  which  are  simply  copied  to  the 

terminal;  special  characters,  which  are  used  for  cursor  control; 
and  conversion  specifications,  which  are  used  for  converting  and 
printing  arguments  which  follow  the  format  string. 

Each  conversion  specification  found  in  the  format  string 
begins  with  the  character  Following  the  ’$’  there  may  be: 

-  an  optional  plus  or  minus  sign  which  specifies  right 
or  left  adjustment  of  the  converted  argument  in  the 
indicated  field. 

an  optional  digit  string  representing  a  field 
repetition  factor.  If  it  is  not  present,  it  is 


U3 


assumed  to  be  1 
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a  character  which  indicates  the  type  of  conversion  to 
be  a ppl ied  . 

an  optional  digit  string  specifying  a  ’MINIMUM'  field 
width  (i.e.,  the  field  to  be  printed  may  actually  be 
larger  than  specified,  but  it  will  not  be  smaller  than 
specified);  if  the  converted  argument  has  fewer 
characters  than  the  field  width,  it  will  be  padded  (on 
left  or  right,  depending  on  the  field  conversion  type 
and  the  field  adjustment  indicator)  with  blanks  to 
make  up  the  field  width.  If  the  character  is 

placed  in  this  position,  the  next  argument  in  the  list 
(the  one  that  follows  the  argument  to  be  printed)  is 
used  to  obtain  the  minimum  field  width. 

an  optional  period  ('.')  which  serves  to  separate  the 
field  width  from  the  next  digit  string. 

-  an  optional  digit  string  (the  precision)  which 

specifies  the  number  of  digits  to  be  printed  to  the 
right  of  the  decimal  point  of  a  single  or  double 
precision  number,  or  the  maximum  number  of  characters 
to  be  printed  from  a  character  string.  If  the 
character  is  placed  in  this  position,  the  next 
argument  in  the  list  of  arguments  is  used  to  obtain 
the  maximum  field  width. 
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S)  N  =  TRMCET (  '  C AZC ' ,  S) 

N  s  1;  S  s  "abed _ efg_12jt" 

5)  N  =  TRMGET (' $A$C£C$C  •  ,  S,  T,  U,  V) 

II  S  4;  S  =  "abed";  T  =  U  =  *  '  V  =  ' e ’ 

(Note:  *C*  conversion  specifier  suppresses  space  skipping) 

The  following  example  shows  how  the  'execution  time*  field  width 
can  be  used. 

10)  N  r  TRMCET ( ' $A*$A* ' ,  S,  2,  T,  5) 

N  =  3;  S  =  "abc" ;  T  =  "d _ ef" 

6.1.4  Some  Notes  Cn  Terminal  I/C  - 

Both  TRMGET  and  TRMPUT  are  written  in  assembly  language. 
TRMGET  and  TRMPUT  are  entry  points  into  the  routines  FILGET  and 
FILPUT,  respectively  (see  Section  6.3).  Essentially,  the  terminal 
I/O  routines  can  be  thought  of  as  special  cases  of  FILGET  and 
FILPUT. 

A  call  to  TRMGET  is  equivalent  to: 

CALL  FILGET  (terminal  LUH,  format-string,  argl  ...) 

A  call  to  TRMPUT  is  equivalent  to: 

CALL  FILPUT  (terminal  LUN,  format-string,  argl  ...) 
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Note : 

Each  character  is  represented  by  a  single  element  in  an 
integer  array.  However,  for  convenience , the  characters  will  be 
displayed  here  as  contiguous  character  strings,  addressed  via  the 
name  of  the  array.  Also,  there  is  an  ECS  symbol  attached  to  the 
end  of  all  the  character  strings  enclosed  in  double  quotes.  When 
the  optional  field  width  portion  cf  the  'A'  conversion 
specification  is  missing,  the  input  field  is  a  string  of  non-space 
characters.  All  initial  space  characters  are  skipped  over  and  the 
input  field  is  TERMINATED  EY  A  SPACE  CHARACTER  or  a  NEW  LIME.  If 
the  field  width  is  specified,  then  any  initial  space  characters  are 
skipped  over,  and  the  FIELD  WIDTH  or  a  NEW  LINE  TERMINATES  the 
input  field. 


2) 

N 

=  TRMGET ( •$2A3f ,  S, 

T) 

N  =  2;  S  =  "abc" , 

t  =  "d _ " 

3) 

N 

=  TRMGET ( *  $ / A  $A5', 

S) 

N  =  1;  S  =  "efg_l 

11 

4) 

N 

=  TRMGET ( ' $A  $A  $A ' 

,  S,  T,  U) 

N  =  3;  S  =  -’abed";  T  =  "efg";  U  =  "12j5" 

5)  N  =  TRHGET(»$/A3  $A 1  $/2A3  $C  •  ,  S,  T) 

N  =  2;  S  s  "d";  T  =  *5*  (no  EOS;  represented  by  single 

quotes) 

6)  H  =  TRMGET ( ' $/2A  $A  '  ,  S) 

N  =  1;  S  =  ”1235” 

7)  N  =  TRMGET ( ’ : X2$A  :P$A  : PS  $A • ,  S,  T,  U) 

N  =  3;  S  =  "cd";  T  =  "abed";  U  =  "fg" 
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The  conversion  characters  and  their  meanings  are  as 

follows : 

I  -  The  argument  (1  word  long)  is  converted  to  a  decimal 
integer.  If  an  adjustment  indicator  is  not  present 
in  the  conversion  specification,  the  resulting  output 
character  string  will  be  right  adjusted  within  its 
field. 

H  -  The  argument  is  considered  a  half  integer  (1  byte 
long)  Default  field  adjustment  is  'right'. 

L  -  The  argument  is  considered  a  long  integer  (2  words 
long)  Default  field  adjustment  is  'right'. 

C  -  The  argument  (1  word  long)  is  printed  out  as  an 
octal  number.  The  resulting  output  string  wil  be 
right  adjusted  in  its  output  field,  when  a 
justification  indicator  is  not  present. 
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A  -  The  argument  is  taken  to  be  a  string  of  characters. 
The  characters  are  stored  in  an  integer  array,  one 
character  per  integer.  Characters  from  the  string 
are  printed  until  an  end  of  string  character  (0)  is 
reached,  or  until  the  number  of  characters, 
indicated  by  the  precision,  is  exhausted.  If  an 
adjustment  indicator  is  not  present  in  the 
conversion  specification,  the  resulting  output 
character  string  will  be  left  justified  in  its 
output  field. 

S  -  The  argument  is  taken  to  be  a  character  string.  The 
only  difference  between  the  'S'  and  'A'  conversion 
specifiers  is  that  the  characters  to  be  printed  are 
stored  in  tne  FORTRAN  hollerith  data  type,  instead 
of  the  FORTRAN  integer  dat.'.  type. 

F  -  The  argument  is  taken  to  be  a  single  precision 
floa* ing  point  number  and  is  converted  to  the 
decimal  notation  of  the  form  [ - ]mmm .nnnnnnn ,  where 
the  length  of  the  string  of  n’s  is  defined  by  the 
’precision’  specification.  The  default  ’precision’ 
is  7.  Default  field  adjustment  is  to  the  right. 
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E  -  The  argument  is  taken  to  be  a  single  precision 
floating  point  number  and  is  converted  to  the 
decimal  notation  of  the  form  [- ]m.nnnnnnnE(  +  or  -)ee, 
where  the  length  of  the  string  of  n's  is  defined  by 
the  'precision'  specification.  The  default  'precison' 
is  7.  The  default  field  adjustment  is  to  the  right. 

D  -  The  argument  is  taken  to  be  a  double  precision 

floating  point  number  and  is  converted  to  the  decimal 
notation  of  the  form  [- ]m.nnnnnnnnnnnnnnnnD(+  or  -)ee, 
where  the  length  of  the  string  of  n's  is  defined  by 
the  'precision'  specification.  The  default  precision 
is  16.  Default  field  adjustment  is  to  the  right. 


If  no  recognizable  character  appears  af^er  the  that 
character  is  printed;  thus  '$'  may  be  printed  by  the  usage  of  the 
string  ' $$ ' . 
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The  following  lines  contain  some  example  usages  of  conversion 
specifications  and  their  resultant  output  ( NCTE,  represents  a 
space  ('  ')  position). 


if  STR  =  'abode' 

if  INT  =  578 

if  FLT  =  352. 7C9 

$A  =  abode 

$1  =  578 

$F  =  352.709 

$-A  =  abode 

$-1  =  578 

$-F  =  352.709 

$+S  =  abode 

$+1  =  578 

$+F  =  352.709 

$A  3 . 3  =  abc 

$12  =  578  (*) 

$F5.2  =  352.71 

$S3 • 3  =  abc 

$-12  =  578 

$F5.2  =  352.71 

$+A3*3  =  abc 

$+13  =  578 

$+F5 . 2  =  352.71 

$S7  =  abode 

$-15  =  _ 578 

$F9.4  =  _352. 7090 

$-A7  =  abode 

$-15  =  578 _ 

$-F9.4  =  352.7090_ 

$+A7  =  _ abode 

$+15  =  _ 578 

$+F9.4  =  _352. 7090 

(*)  An  example  of  what  happens  when  a  numeric  field 
width  exceeds  its  "minimum”  field  width. 
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The  following  lines  show  examples  cf  the  execution  time  field 
width  and  precision  portions  of  a  conversion  specification. 

if  STR  =  'abode',  I  =  3 »  snd  J  =  7,  then, 

CALL  TRMPUT  ('$A*',  STR,  I) 

'abode'  is  printed  at  the  terminal 
CALL  TRMPUT  ('$A.*',  STR,  I) 

'abc'  is  printed  at  the  terminal 
CALL  TRMFUT  C$A*.*',  STR,  J,  J) 

'abode _ '  is  printed  at  the  terminal 

CALL  TRMFUT  C$A5.*',  STR,  J) 

'abode'  is  printed  at  the  terminal 

TRMPUT  signals  its  failure  to  write  to  the  terminal  by  an 
approriate  error  message. 

6.1.3  TRMGET  - 

The  calling  sequence  for  TRMCET  is: 

N  =  TRMGET  (format-string,  argl,  arg2,  ...) 

TRMGET  is  a  terminal  input  function  subprogram  (It  must  be 
declared  as  a  FORTRAN  integer).  It  reads  characters  from  the 
terminal,  interprets  them  according  to  a  format,  and  stores  the 
result  ir.  its  arguments.  The  format  string  usually  contains 
specifications  which  are  used  to  direct  interpretation  of  input 
sequences . 
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A  format  string  may  contain: 


The  special  string  characters  representing  blanks, 
tabs,  newlines,  backspaces,  linefeeds,  carriage  re¬ 
turns,  or  formfeeds,  which  are  ignored  (these  will 
be  known  as  'space'  characters). 

Ordinary  characters  (not  '$')  which  are  expected  to 
match  the  next  non-space  character  of  the  input 
stream  . 

Conversion  specifications,  consisting  of  the  character 
'$',  an  optional  assignment  suppressing  character  '/’, 
an  optional  space  skipping  suppressing  character  '-', 
an  optional  numerical  field  repetition  factor,  a  con¬ 
version  character,  and  an  optional  numerical  'MAXIMUM' 
field  width  specifier  (i.e.,  the  field  to  be  read  may 
actually  be  smaller  than  specified,  but  not  larger 
than  specified . ) 

Note,  the  maximum  field  width  specifier  may  be  re¬ 
placed  by  the  character  which  indicates  that 

the  argument  following  the  one  currently  being  pro¬ 
cessed  contains  the  value  of  the  maximum  field  width. 
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A  conversion  specification  is  used  to  direct  the  conversion 
of  the  next  input  field;  the  result  is  placed  in  the  varia¬ 
ble  pointed  to  by  the  corresponding  argument,  unless 
assignment  suppresion  was  indicated  by  the  V  character. 

The  assignment  suppression  character  ’/’  directs  TRKCET  to 
skip  over  the  specified  type  of  field  in  the  input  stream. 

An  input  field  is  defined  as  a  string  of  non-space  charac¬ 
ters.  However,  an  exception  can  occur  when  using  an  'A’ 
or  'S'  conversion  specification.  See  'A'  description. 

The  following  conversion  characters  are  permissable: 

$  indicates  that  a  single  ’$*  character  is  expected 
in  the  input  stream  at  this  point;  no  assignment 
is  done. 

I  indicates  that  a  decimal  integer  is  expected  in 
the  input  stream;  the  corresponding  argument 
should  be  of  type  integer. 

H  indicates  that  a  decimal  integer  is  expected  in 
the  input  stream;  the  corresponding  argument 
should  be  of  type  half  integer  (i.e.,  in  DEC 
FORTRAN  the  type  is  LOGICAL* 1  or  EYTE ) . 
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L  indicates  that  a  decimal  integer  is  expected  in 
the  input  stream;  the  corresponding  argument 
should  be  of  type  long  integer  (i.e.,  in  EEC 
FORTRAN  the  type  is  INTEGER*1;). 

A  indicates  that  a  character  string  is  expected  in 
the  input  stream;  the  corresponding  argument 
should  be  an  integer  array  large  enough  to 
accept  the  string  and  an  end-of-str ing  (ECS  =  0, 
the  null  character)  symbol,  which  will  be  added. 
If  an  optional  field  width  is  not  specified,  the 
input  record  is  terminated  by  either  a  space 
character  or  a  newline. 

If  an  optional  field  width  is  specified,  only 
a  newline  may  terminate  the  input  record  before 
the  end  of  the  field  is  reached.  Thus,  space 
characters  may  be  embedded  in  the  output  field 
only  if  a  field  width  is  specified. 

S  indicates  that  a  character  string  is  expected; 
this  specification  is  identical  to  the  'A' 
specification  except  that  the  correspond ing  arg¬ 
ument  should  be  a  HOLLERITH  field  (i.e.,  in  DEC 
FORTRAN  this  is  the  variable  LCGICAL*1). 
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E  indicates  that  a  floating  point  number  is 
F  expected  in  the  input  stream;  the  correspond ing 
argument  should  be  a  single  precision  'REAL' 
variable.  The  input  format  for  a  floating  point 
number  is  a  string  of  numbers,  possibly  contain¬ 
ing  a  leading  minus  sign,  followed  by  an  optional 
exponent  field  containing  an  ’E'  cr  'D',  fol¬ 
lowed  by  a  possible  signed  integer. 


D  indicates  that  a  floating  point  number  is  ex¬ 
pected  in  the  input  stream;  the  corr espond ing 
argument  should  be  a  double  precision  'REAL' 
variable.  The  input  format  is  identical  to  that 
of  the  'E',  *F’  format. 

C  indicates  that  a  single  character  is  expected  in 
the  input  stream;  the  correspond ing  argument 
should  be  an  integer  variable.  Rote ,  no  ECS 
symbol  is  tacked  on  the  end  of  the  character 
in  the  output  field. 


TRKGET  returns,  as  its  value,  the  number  of  successfully 
matched  and  assigned  input  items.  This  can  be  used  to  decide  how 
many  input  items  were  found. 
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If  a  program  termination  symbol  (a  null  line  or  carriage 
return)  is  encountered  by  TRKC-ET,  a  -1  is  returned. 

If  the  CLPARS  universal  help  symbol  (?)  is  found  as  the  first 
non-space  character  in  the  input  record,  a  -2  is  returned . 

The  following  lines  contain  usage  examples  of  the  above 
conversion  characters. 

Current  input  string:  ”57 9 _ 3 ^ _ 6 215 8"  * 

1)  Ns  TRMGET  (»$I  $11  $211',  J,  K,  L,  M) 

N  s  4,  J  =  5797;  K=3;L=4;Ms6 

2)  Ns  TRMGET (’$212  $21’,  J,  K,  L,  M) 

N  s  4;  J  s  57?  K  t  9;  L  s  3^;  M  =  62158 

3)  N  S  TRMGET ( ' $/I  $1’  ,  J) 

N  s  1;  J  s  34 

4 )  Ns  TRMGET ( '$/2I$I '  ,  J) 

N  s  1;  J  s  62158 

5)  Ns  TRMGET ( ' $/2I2  $1  '  ,  J) 

Ns  T;  J  s  34 

Current  input  string:  ”abcd _ efg_12j5" 

1 )  N=  TRMGET ( ' $A  $A3' ,  S,  T) 

N  s  2;  S  s  "abed”;  T  s  "efg”  (see  note  on  following  page) 


*  ’  ’  is  strictly  a  place  holder  for  spaces,  i.e.,  a  space 
character  really  should  appear  where  '  '  does. 
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Rote : 

Each  character  is  represented  by  a  single  element  in  an 
integer  array.  However,  fcr  convenience , the  characters  will  be 
displayed  here  as  contiguous  character  strings,  addressed  via  the 
name  of  the  array.  Also,  there  is  an  ECS  symbol  attached  to  the 
end  of  all  the  character  strings  enclosed  in  double  quotes.  When 
the  optional  field  width  portion  of  the  ’A’  conversion 
specification  is  missing,  the  input  field  is  a  string  of  non-space 
characters.  All  initial  space  characters  are  skipped  over  and  the 
input  field  is  TERMINATED  EY  A  SPACE  CHARACTER  or  a  NEW  LINE.  If 
the  field  width  is  specified,  then  any  initial  space  characters  are 
skipped  over,  and  the  FIELD  WIDTH  or  a  NEW  LINE  TERMINATES  the 
input  field. 

2)  N  =  TRMGET ( 1  $2A3  *  ,  S,  T) 

N  =  2;  S  =  "abc" ,  t  =  "d _ " 

3)  N=  TRMGET ( ’ $/A  $A5  •  ,  S) 

N  =  1;  S  s  "efg_l” 

M )  M=  TRMGET (*$A  $A  $A  ’  ,  S,  T,  U) 

N  s  3;  S  s  "abed";  T  s  "efg”;  U  s  ”12j5” 

5)  N  s  TRMGET ( ’$/A3  $A 1  $/2A3  $C  •  ,  S,  T) 

N  s  2;  S  s  "d";  T  s  »5'  (no  EOS;  represented  by  single 

quotes ) 

6)  Ns  TRMGET  C$/2A  $A  '  ,  S) 

N  s  1;  S  s  "12 J5B 

7)  N  =  TRMGET ( • : X2$A  : P$A  : PS  $A » ,  S,  T,  U) 

N  s  3;  S  s  "cd";  T  s  "abed”;  U  s  ”fg" 
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£  )  Ns  TRMCET ( ' £AZC ' ,  S) 

N  s  1;  S  s  "abed _ efg_12jt" 

9)  M  =  TRMGET ( ’ $A$C£C$C '  ,  S,  T,  U,  V) 

U  =  4;  S  =  "abed”;  T  =  *_•;  U  =  V  =  'e* 

(Note:  'C'  conversion  specifier  suppresses  space  skipping) 

The  following  example  shows  how  the  'execution  time1  field  width 
can  be  used. 

10)  N  =  TRMGET (’ $A*$A* ’  ,  S,  3,  T,  5) 

N  =  5?  S  =  "abc";  T  =  "d _ ef" 

6.1.4  Some  Notes  Cn  Terminal  I/C  - 

Both  TRMGET  and  TRMPUT  are  written  in  assembly  language. 
TRMGET  and  TRMPUT  are  entry  points  into  the  routines  FILGET  and 
FILPUT,  respectively  (see  Section  6.3).  Essentially,  the  terminal 
I/O  routines  can  be  thought  of  as  special  cases  of  FILGET  and 
FILPUT. 

A  call  to  TRMGET  is  equivalent  to: 

CALL  FILGET  (terminal  LUN,  format-string,  argl  ...) 

A  call  to  TRMPUT  is  equivalent  to: 

CALL  FILPUT  (terminal  LUN,  format-string,  argl  ...) 
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6.2  CLFARE  TERMINAL  GRAFHICS  INFUT/CUTFUT 

Along  with  the  terminal  input/cutput  routines,  CLEARS  has  a 
set  of  graphics  input  and  output  routines.  Most  of  the  output 
routines  are  utilities  closely  resembling  the  FLTKAF  FCRTRAI. 
routines  requested  by  the  buyer.  The  graphics  input  routine, 
necessary  for  some  CLPARS  functions,  is  not  in  the  FLTKAF  routines, 
and  had  to  be  written.  The  following  sections  discuss  in  mere 
detail  the  actual  utilities  chosen  to  be  part  of  the  CLPARS 
graphics  I/O. 

6.2.1  Graphics  Input  Utility  - 

The  graphics  input  routine  (GIN)  is  used  to  obtain  graphic 
display  screen  coordinates.  First,  this  routine  places  the 
graphics  terminal  into  graphics  input  mode.  It  then  waits  for  the 
return  of  a  graphics  screen  coordinate  and  the  character  that  was 
typed  in  to  send  the  coordinate.  If  the  display  terminal  does  not 
have  cursor  wheels,  a  joystick,  or  some  other  hardware  graphics 
cursor  manipulator,  GIN  must  take  over  this  function  (i.e.,  special 
characters  will  have  to  be  reserved  for  graphics  cursor  movement; 
possibly  1-left,  r-right,  u-up,  d-down).  This  routine  is  a 
system-dependent  program. 

GIN'S  program  usage  would  be: 

CALL  GIN (X ,  Y,  CHAR) 

where  all  of  GIN'S  arguements  are  of  integer  type.  X  and  Y  are  the 
terminal  horizontal  and  vertical  coordinates,  respectively.  CHAR 
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uill  be  the  character  used  to  send  the  coordinates  back  to  the 
calling  program. 

6.2.2  Graphics  Output  Utilities  - 

The  following  depicts  the  type  of  graphics  output  functions 
that  CLPARS  needs  to  have  for  its  display  purposes: 

the  ability  to  place  a  text  string  at  a  specified  point 
the  ability  to  draw  lines 

-  the  ability  to  erase  the  screen  and  ,,home,,  (move  to  the  upper 
left  corner)  the  cursor. 

The  subsequent  paragraphs  describe  the  routines  that  were 
chosen  from  the  PLTMAP  utilities  for  the  OLPARS  graphics  display, 
plus  two  additional  routines  written,  MOVE  and  RCTN'GL. 

6.2.3  TEXT  - 

This  routine  places  a  string  of  text  on  the  graphics  display, 
starting  at  a  given  set  of  coordinates.  The  screen  coordinates  are 
relative  screen  coordinates  used  to  redefine  the  origin.  Each 
character  of  the  string  resides  in  a  separate  integer,  and  the  last 
integer  position  in  the  string  must  contain  zero. 
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6.2.4  MARK  - 

This  routine  places  a  given  marker  at  a  specified  set  cf 
screen  coordinates.  The  markers  are  those  specified  in  the  PLTMAP 
utilities . 

CLPARS  uses  this  in  its  two-space  display  programs. 

6.2.5  LINSEC  - 

This  routine  draws  a  line  between  two  specified  points.  It  is 
used  to  draw  display  borders  and  data  and  logic  tree  structures. 

6.2.6  ERASE  - 

This  routine  erases  the  terminal  screen  (and  "homes"  the 
cursor,  if  not  done  automatically). 

6.2.7  MOVE  - 

This  routine  moves  the  terminal  screen  cursor  to  specified 
terminal  coordinates. 

6.2.8  RCTHGL  - 

This  routine  draws  the  outline  of  a  rectangle  given  the 
coordinates  of  two  opposite  corners. 
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6.5  CLEARS  TEXT  FILE  INPUT/CUTPUT 

Any  CLPARS  text  file  input  routine  will  need  a  way  to  read 
numeric  characters  from  a  file  and  convert  then  to  binary 
information.  Likewise,  a  file  output  routine  needs  a  way  to 
convert  binary  data  into  printable  characters.  The  following  two 
sections  describe  the  subroutines  that  will  enable  the  CLPARS  file 
I/O  routines  to  operate. 

6.3. 1  FILGET  - 

The  calling  sequence  for  FILGET  is: 

N  =  FILGET  (lun,  format-string,  arg  1,  arg  2,  ...) 

FILGET  is  a  file  input  function  subprogram.  It  reads 

characters  from  a  file,  specified  by  a  logical  unit  number  (lun), 

interprets  them  according  to  a  format  (identical  to  TRMGET  format), 
and  stores  the  results  in  its  arguments.  The  format  string  usually 
contains  specifications  which  are  used  to  direct  interpretation  of 
input  sequences.  See  Section  6.1.5.  for  further  information  on 
the  format  string. 

FILGET  returns  as  its  value  the  number  of  successfully  matched 
and  assigned  input  items.  When  the  end  of  the  file  is  reached, 
FILGET  will  return  a  -1  as  its  function  value.  (On  RSX-11M,  if  the 
file  being  read  is  actually  a  terminal,  a  CTRL-Z  will  simulate  the 
end  of  file.)  When  the  terminal  is  being  read  by  FILGET,  a  program 

termination  symbol  (null  line)  will  also  cause  a  -1  to  return. 
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This  is  not  true  when  FILCET  is  reading  a  file. 

6.2.2  FILFUT  - 

The  calling  sequence  for  FILPUT  is: 

CALL  FILPUT  (lun,  format-string,  arg  1,  arg  2,  ...) 

FILPUT  is  a  file  output  subprogram.  It  formats,  converts,  and 
prints  its  arguments  to  a  file  under  control  of  a  format  string 
(see  Section  6.1.2.).  The  file  is  specified  by  a  logical  unit 
number  ( LUN ) . 

FILPUT  signals  its  success  or  failure  at  writing  to  the  file 
with  an  appropriate  error  message.  Both  FILGET  and  FILPUT  are 
assembly  I/C  routines. 

6.3.2  Printing  -  CLPARS  Output  To  A  Computer  Printer  - 

There  are  a  few  CLPARS  programs  that  give  the  user  the  ability 
to  obtain  printable  listings  (or  text  files)  of  a  variety  of  CLPARS 
data  forms.  Cluster  plots,  rank  order  matrices,  and  confusion 
matrices  are  a  few  examples  of  the  CLPARS  data  forms  available  for 
printing . 

The  print  utility  commands  create  a  file  within  the  system,  to 
store  the  output  to  be  generated.  Once  the  printer  listing 
generation  is  complete,  the  utility  makes  a  call  to  a  system 
dependent  program  (PRINTR)  that  will  send  the  file  to  a  printer  for 
printing  . 
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The  following  is  a  list  of  print  utility  commands  that  may  be 
implemented.  (The  starred  commands  have  not  yet  been  implemented). 

PRTRKK*  -  used  for  rank  order  displays  or  probability  of 
confusion  or  discriminant  measure. 

PRTLS  -  used  to  obtain  certain  basic  statistical 

information  about  a  data  base. 

PRTCM  -  used  to  print  out  a  confusion  matrix. 

PRTCLP*  -  used  to  print  out  a  cluster  plot. 

PRTIDX  -  used  to  index  a  particular  display  or  set  of 

display  symbols,  and  obtain  information  about 
the  vector  that  the  display  symbol  represents. 

PRTLCG  -  used  to  list  the  logic  of  the  current  logic 
tree . 

PRTOSD*  -  used  to  produce  a  printer  simulation  of  a 

one-space  display  (micro  view  format  only). 


162 


Terminal  and  Text  File  Input/Cutput  --  6 
CLPARS  TEXT  FILE  INPUT/CUTPUT 

6.3*^  CLPARS  Data  Tree  Input/Cutput  - 

Users  of  CLPARS  will  probably  have  their  data  on  various 
mediums,  such  as  disk  or  magnetic  tape.  CLPARS  must  be  able  to 
read  and  convert  a  user  text  file,  containing  data,  into  an  CLPARS 
tree  (that  is,  create  a  tree  information  and  tree  vector  file  with 
the  users'  data) . 

Also,  a  user  may  want  to  take  an  existing  CLPARS  data  tree  and 
create  a  text  file  of  vectors  to  edit.  Therefore,  CLFARS  must 
convert  its  data  tree  to  a  "system"  text  file. 

To  make  the  programming  of  the  above  functions  as  minimal  as 
possible,  all  input  and  output  data  will  have  the  same  CLPARS 
logical  format.  This  format  is  specified  in  the  programs  FILED! 
and  FILECUT  (for  the  RSX-1 1M  system).  Note,  the  output  from 
FILECUT  can  be  used  as  input  to  FILEIN. 

6.2*5  Some  Motes  Cn  Terminal  And  Text  File  I/O  - 

The  internal  binary  representation  of  character  strings  within 
a  computer  program  varies  from  program  language  to  program 
language,  from  operating  system  to  operating  system,  and  from 
computer  to  computer.  The  terminal  and  file  I/C  routines  (TRMGET, 
TRMPUT,  FILGET,  FILPUT)  can  alleviate  this  problem  of  internal 
character  representation  by  using  an  integer  index  (into  a  table  of 
characters)  which  points  to  the  character  to  be  represented.  This 
would  make  CLPARS  I/O  character  strings  system  independent. 


163 


Terminal  and  Text  File  In put/Cutput  —  C 
CLFARS  TEXT  FILE  INPUT/CUTFUT 


Under  RSX-1 1M  we  have  chosen  not  to  include  such  a  table 
within  the  terminal  and  file  I/O  routines,  because  the  ASCII  7  bit 
character  set  and  its  internal  form  within  Digital  Equipment 
Corporation  FORTRAN  already  give  us  a  convenient  integer 
representation  for  character  strings. 

Even  though  the  terminal  I/O  routines  appears  to  be  a  special 
case  of  file  I/O  routines,  there  are  some  differences.  For 
instance,  the  terminal  I/O  routines  will  automatically  "open"  the 
terminal  logical  unit  number  (if  it  is  not  open)  while  the  file  I/O 
routines  do  not. 
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7 . C  CLFARS  FORTRAN  CODE  GENERATION 

A  user  may  create  FORTRAN  code,  which  becomes  a  subroutine 
called  by  other  programs.  This  method  is  used  in  the  measurement 
transformation  command  (MEASXFRM)  .  Note,  the  FORTRAN  code 
generation  program  (in  this  case,  MEASXFRM)  may  or  may  not  be  able 
to  call  up  a  FORTRAN  compiler  to  compile  the  FORTRAN  subroutine. 
On  systems  that  do  not  allow  initiation  of  a  FORTRAN  compiler  from 
within  a  program,  the  user  will  have  to  compile  his/her  CLPARS 
generated  FORTRAN  program.  Under  FSX-11M,  CLPARS  will  be  able  to 
call  the  FORTRAN  compiler  (via  a  command  file). 

Example  of  user  generated  FORTRAN  code: 

Function  Description:  MEASXFRM  is  a  means  of  transforming  one  data 
set  with  dimensionality  M  into  another  data  set  of  dimensionality  N 
(N  may  or  may  not  =  M) .  This  transformation  is  done  by  means  of 
character  arithmetic  expressions.  Measurement  'i’  in  the  new  tree 
is  symbolized  by  NM(i).  Measurement  *  i'  in  the  old  tree  is 
symbolized  by  CM(i). 


Other  CLFAF.S  Features  --  7 
CLPARS  FORTRAN  CCDE  GENERATION 

For  example,  suppose  we  have,  as  the  current  data  set,  a  tree 
with  dimensionality  four  and  wish  to  create  another  tree  with 
dimensionality  five.  Furthermore,  suppose  each  measurement  in  the 
new  tree  is  to  be  the  same  as  that  in  the  old  tree,  with  the 
exception  that  measurement  five  of  the  new  tree  is  to  equal  the  sum 
of  measurements  three  and  four  of  the  old  tree. 

The  user  would  enter  the  following  FORTRAN  statements: 

NK  ( 1  )  =  OM  ( 1  ) 

NK  ( 2 )  =  CMC  2) 

NM(3)  =  CM(3) 

NM(4)  =  CMC  4) 

NM  (  5  )  =  CMC  3)  +  0M(4) 

In  the  RSX-1 1M  version  of  portable  CLPARS,  MEASXFRM  is 
implemented  via  a  command  file.  An  editor  is  initiated  to  accept 
the  above  FORTRAN  statements.  The  statements  are  inserted  into  a 
subroutine  which  is  compiled  and  linked  with  the  rest  of  the 
MEASXFRM  program.  The  command  file  then  causes  the  program  to 
execute.  For  more  details,  see  MEASXFRM  in  the  CLPARS  VI  Program 
Specifications. 

An  additional  capability  to  save  the  FORTRAN  subroutine  is 
available  to  the  user.  This  way,  (s)he  can  easily  use  the 
measurement  transformation  created  under  MEASXFRM  many  times. 
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7.1  CLFARS  ECCLEAN  STATEKEM  INTERPRETER 

There  are  several  other  instances  where  an  CLPARS  user  ray 
enter  linguistic  or  Ecolean  statements  in  the  course  cf  analysis 
(e.g.,  linguistic  partition  in  structure  analysis,  linguistic  group 
logic  or  linguistic  reject  regions  in  logic  design).  In  each  of 
the  cases,  the  user  enters  exactly  one  statement  and  vectors  are 
tested  against  this  statment  to  see  if  a  true  or  false  value  is 
obtained.  In  oraer  to  make  these  programs  (LINCPART,  LINGLCC  and 
LINGRJCT)  system  independent,  an  interpreter  program.  (INTRF5; 
Interpret  Eoolean)  is  incorporated  into  CLPARS  to  perform  the  above 
test.  This  progirm,  which  will  be  written  in  FCRTRAN,  will  be 
system  independent. 

The  Boolean  statement  may  consist  of  the  following 

information : 

1.  Measurement  positions  in  a  data  vector. 

2.  Floating  point  numbers 

3-  Logical  Cperators 

4.  Arithmetic  Operators 

5.  Arithmetic  Functions 
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Additional  advantages  cf  this  scheme  are: 

o  No  command  file  need  be  created, 
o  User  interaction  is  simplified. 

o  The  interpreter  can  check  the  syntax  cf  the  Eoolean 
statement  and  it  returns  with  an  error  flag  if  the 
syntax  is  incorrect. 

7.2  BATCH  PROCESSING  It.'  CLPARS 

Eatch  processing  in  CLPARS  is  a  system  dependent  operation. 
For  instance,  KULTICS,  a  multi-user  time  sharing  computer  system, 
allows  "batch"  processing  (known  as  absentee  jobs)  to  occur  via  a 
command  file  (see  Figure  7-1)*  The  programs  tc  be  run,  along  with 
the  input  to  these  programs,  are  all  contained  in  a  special  command 
file.  The  output  from  the  programs,  directed  to  a  user  terminal, 
is  placed  in  a  special  file  within  the  user's  directory  for 
examination  at  a  later  date.  The  absentee  job  is  treated  as  if 

there  was  a  user  at  some  terminal. 

/ 

It  is  obvious  that  considerable  familiarity  with  the 
interactive  queries  of  MCOS  (MULTICS  OLPARS  Operating  System) 
functions  is  necessary  since  all  queries  must  be  correctly  answered 
with  the  command  file.  The  absentee  job  in  Figure  7-1  could  be 
performed  on  a  number  of  data  sets  by  simply  changing  the  tree  name 
"datatree"  to  the  names  of  other  data  sets. 
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Order  the  KSX-1 IK  . ystem ,  the  "AT"  processor  hardies  the 
command  file  (batch)  processing.  In  this  system,  the  program's 
terminal  input  dees  net  come  from  a  file,  and  the  program's 
terminal  output  is  not  put  into  a  file.  This  means  that  the  "AT" 
processor  does  not  treat  a  command  file  as  a  separate  terminal. 
(Hence,  it  will  not  be  used  in  the  RSX-1 1M  portable  CLPARS). 

To  make  this  "batch"  processing  transportable  to  different 
machines,  there  should  be  two  separate  CLPARS.  The  difference 
between  the  two  systems  will  occur  in  the  terminal  I/G  packages; 
one  package  will  communicate  directly  with  the  terminal,  the  other 
(in  the  batch  system)  will  communicate  with  files  (i.e.,  batch 
OLPARS  will  get  its  commands  from  one  file  and  put  its  terminal 
output  into  another  file). 

The  total  size  of  the  batch  system  could  also  be  reduced  by 
keeping  only  the  programs  that  create  character  output  in  the 
system.  This  decision  will  be  left  up  to  the  people  who  want  a 
batch  version  of  CLPARS  on  their  computers. 

An  example  of  an  CLPARS  command  (batch)  file  cai.  be  found  in 
Figure  7-2. 
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cwd  >  udd  >  C  >  CLPARS 

restore  data  tree 
4 

SCO 

fisher 

0 

1 

8 

yes 

and 

yes 

printer) 

no 

logout 


(change  working  directory 
to  CLPARS) 

(restore  the  design  data  set) 

(answer  questions  related  to 

console  type  and  baud  rate) 

(invoke  fisher  pairwise 
logic) 

(select  option  0) 

(select  1  threshold) 

(set  minimum  vote  count  to  8) 
(hard  copy  confusion  matrix 

list  of  errors  to  line 

(halt  fisher  calculation) 


Figure  7-1  A  MULTICS  Command  File 


Other  CLFARS  Features  -- 

batch  frccessing  in  clpae 


SETLS 

(set  data  set) 

/ 

TREE1 

(answer  questions  related 
treename  and  nodename 

to 

NODE  1 
/ 

(for  the  current  data  set 

desired ) 

FISHER 

(invoke  fisher  pairwise  logic) 

/ 

0 

(select  option  0) 

1 

(select  threshold) 

4  (set  minimum  vote  count  to  4) 

YES  (send  confusion  matrix  and  a  list 

YES  of  errors  to  line  printer) 

NC  (halt  fisher  calculation) 

/ 

NOTE:  V"  delimits  answers  to  program  questions 


Figure  7-2  Example  of  CLPARS  Command  File 
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Vvithin  an  RSX-1  1M  CLPARS,  the  batch  mode  will  be  hanalea  in 
the  following  manner.  A  separate  "batch"  CLPARS  would  be  in 
existance.  A  user  would  create  the  command  file  via  an  editor 

program.  (S)He  then  runs  the  batch  CLPARS  (ECLP)  while  in  his/her 
CLPARS  directory.  BCLP  executes  the  command  contained  within  the 

command  file.  Cnee  BCLP  is  started  up,  the  user  could  not  run  the 

interactive  version  of  CLPARS,  but  could  run  other  tasks  within  the 
RSX-1 IK  system.  Located  within  the  user's  directory,  would  be  the 
file  containing  all  of  the  terminal  output  from  the  batch  CLPARS 
session.  The  user  could  use  a  system  command  (PIP  for  instance)  to 
view  the  contents  of  the  file  after  execution  of  ECLP. 

7.3  EXPANDABILITY 

Adding  new  applications  programs  to  FCRTRAN  CLPARS,  or 

inserting  additional  options  into  already  existing  programs,  should 
be  a  relatively  simple  task  for  the  following  reasons. 

o  If  a  new  command  is  to  be  added,  the  entire  system 
does  not  need  to  be  recompiled  or  have  its  tasks 
rebuilt.  The  new  program  must  be  compiled  together 
with  the  OLPARS  subroutines  it  needs,  and  its  name 
must  be  inserted  in  the  list  of  allowable  command 
names  that  is  accessed  by  the  CIP  (or  the  operating 
system)  . 
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o  The  modular  construction  of  the  CLEARS  programs  will 
mean  that  a  good  part  of  the  code  for  any  new  program 
will  already  exist. 

o  New  options  in  existing  routines  can  be  programmed  by 
changing  only  the  particular  routine  and,  most 
probably,  by  changing  only  a  few  of  the  subroutines 
of  that  particular  routine.  Many  of  the  CLPARS 
commands  have  been  designed  to  accommodate  additional 
functions  by  adding  subroutines  and  giving  the  user 
additional  options. 


SECTION  8 


SYSTEM  DEPENDENCIES 


In  a  system  as  complicated  as  CLPARS,  where  there  is  a  large 
amount  of  input/  output  with  files,  the  printer,  and  especially  the 
terminal,  there  must  be  system  dependencies  to  handle  these 
features  as  well  as  others.  In  order  to  make  CLPARS  as  portable  as 
possible,  the  system  dependencies  have  been  isolated  into  a  set  of 
routines  that  will  be  called  by  the  rest  of  CLPARS  to  perform  the 
dependent  functions  like  I/C.  In  this  section,  we  review  the 
system  dependent  functions  of  portable  CLPARS  with  explanations 
here,  or  with  references  to  documentation  elsewhere. 

o  Start  Up  and  Sign  Off 

Signing  on  and  off  CLPARS  is  system  dependent.  CLPARS  needs 
an  initialization  routine  to  set  terminal  characteristics  in  files, 
or  initialize  other  files.  When  there  is  no  executive  program,  the 
user  must  call  this  routine  (HELOLP)  when  (s)he  first  starts  up  the 
system.  If  an  executive  command  input  processor  (CIF)  program 
exists,  then  this  initialization  routine  can  be  called 
automatically  for  the  user. 

When  the  operating  system  has  special  interrupt  functions  to 
abort  programs,  signing  off  of  CLPARS  can  be  slightly  tricky.  If 
CLPARS  programs  do  not  have  the  ability  to  catch  the  abort 
interrupt  signal,  it  could  very  well  mess  up  the  CLPARS  file 
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structure.  If  this  is  the  case,  users  should  avoid  the  signal 
abort  feature  on  their  system  when  running  CLPARS.  Under  RSX-1 IN 
FORTRAN,  a  user  may  type  a  control-Z  (~Z)  when  entering  input  to  a 
program.  This  simulates  an  end-of-file  interrupt  signal.  Since 
this  interrupt  can  be  caught  by  programs,  RSX-1 1M  CLPARS  users  need 
not  worry  about  using  it. 

OLPARS  programs  should  leave  gracefully,  so  there  is  a 
standard  procedure  for  exiting  CLPARS  programs.  If  a  user  enters  a 
null  line  during  an  input  session  with  an  ’'OLPARS  program”,  the 
program  will  exit.  To  exit  ’’CLPARS”  (that  is,  the  CLPARS  comand 
level)  the  user  must  type  BYEOLP;  a  null  line  will  not  allow 
system  termination  at  the  command  level. 

o  The  Command  Input  Processor  ( CIP )  (See  Section  2  and 

Appendix  A) 

o  Spawning  (See  Appendix  A) 

o  Compilation  and  Execution  of  FORTRAN  Statements  typed 
in  by  the  user  (see  Section  7.0) 

o  Terminal  and  File  Text  I/O  (see  Section  6) 

o  Use  of  a  "Batch"  OLPARS  (see  Section  7.1) 

o  Programmer  Aid  Options  (see  Appendix  G) 

o  Character  Handling  (see  Section  6) 
oo  character  string  comparisons 
oo  character  string  terminator 
oo  character  string  length  determination 
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o  Processing  bit  maps  in  the  LI  file  (see  Section  4.6) 
o  Creating  "system"  file  names  from  CLPARS  tree  names 

Cn  computer  operating  systems  that  have  file  names  which  are 
smaller  than  CLPARS  tree  names,  a  unique,  algorithmically  generated 
file  name  must  be  produced  from  the  tree  name.  An  alternative 
method  would  be  to  create  a  set  of  unique  file  names,  having 
nothing  to  do  with  an  CLPARS  tree  name.  The  file  name  would  be 
associated  with  the  tree  name  through  some  file  or  table.  (See 
discussion  of  File  Code  Table  in  Appendix  E) . 
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THE  COMMAND  INFUT  PROCESSOR  (CIP) 
or 

How  to  "talk"  to  CLPARS  on  RSX11K  version  3*2 


This  section  describes  the  programs  and  files  necessary  for 
contriving  the  Command  Input  Processor  (CIF),  "login"  function 
(HELCLP),  and  "logout"  function  (EYECLP)  under  the  DEC  operating 
system  RSX11M  version  3.2  (reader  must  be  familiar  with  this 
operating  system) . 

The  CIP  program  only  partially  implements  the  CIP  function. 
Its  job  is  to  prompt  the  user  for  an  CLPARS  comn/and  name  and  make 
sure  what  the  user  has  typed  is  valid  (it  accepts  initial 
substrings  of  all  commands,  except  BYECLP).  It  produces  a  command 
file  which  invokes  the  CLPARS  command  requested  by  the  user 
(explained  later). 

The  CMINIT  program,  which  initializes  the  terminal  screen 
parameters  and  CLPARS  system  directory  string*  in  the  user's 
Communications  (CM)  file,  partially  implements  the  HELCLP  function 
(hello  OLPARS,  or  "logging  in").  It  welcomes  the  user  and  displays 


The  operating  system  manager  must  "install"  the  two  programs 
CIP  and  CMINIT  as  "...CIP"  and  "...CMI",  respectively ,  because 
they  both  need  to  access  their  system  command  line  (via  system 
supplied  subroutine,  GETMCR)  for  the  CLPARS  system  directory 
location . 


Conr.ir.snci  Input  Processor  (CIP)  on  RSX11K  v3.E  --  A 

a  list  of  terminal  types  known  to  CLPARS.  It  asks  the  user  to  name 
the  terminal  type  (s)he  is  using.  The  program  uses  the  name  typed 
in  to  find  a  file  containing  the  screen  parameters  to  he  placed  in 
the  user's  Communications  file.  It  is  important  that  the  correct 
screen  parameters  are  obtained  for  the  given  type  of  terminal; 
otherwise,  erroneous  results  may  occur  when  using  "interactive" 
CLPARS  displays.  CLPARS  essentially  remembers  the  last  terminal  at 
which  the  user  has  "logged  in",  so  supplying  an  empty  response  to 
the  CNINIT  prompt  is  perfectly  safe  as  long  as  the  operator  is  at 
the  same  type  of  terminal  (s)he  has  used  at  his/her  last  CLPARS 
session . 

Three  command  files  complete  the  implementation  of  the  CIP, 
HELOLP,  EYECLP  functions.  The  files  are  "HELOLP.CMD", 
" CLFDIR . CMC"  ,  and  "EYECLP. CMC" .  The  user  "logs"  into  CLPARS  by 
invoking  the  HELOLP  command  file*.  The  command  file  locates  the 
CLPARS  directory  by  invoking  the  "CLPDIR.CME"  file**.  HELCLP  then 
queries  the  user  for  the  "login"  name  assigned  to  him/her  by  the 
CLPARS  manager.  It  uses  the  "login"  name  to  find  out  where  the 
user's  CLPARS  directory  is  located.  Next,  the  CKINIT  program  is 


*  The  user  may  type  "gHELOLP"  or 

"@[directory-specification]HELOLP"  to  start  up  the  command 
file.  A  "login"  request  will  follow.  To  skip  the  "login" 
request,  the  user  may  type  "@HELOLP  Cuser  name>",  where 
<user  name>  is  the  user's  "login"  name. 

**  "CLPDIR.CME"  must  be  located  in  the  same  directory  in  which 
"HELOLP.CMD"  resides.  "CLPDIR.CME"  should  be  modified  by 
the  person  responsible  for  maintaining  CLPARS  sc  that  it 
points  to  the  directory  in  which  all  the  CLPARS  commands 
reside  (the  CLPARS  system  directory) 
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invoked  by  HELCLP.  Finally  the  CIP  program  is  activated  and  CLFAHS 
is  ready  to  do  work  for  the  user. 

The  command  file  created  by  the  CIP  program  (called 
"CLPCC.M.CML")  is  invoked  by  the  KELOLP  command  file  after  the  CIF 
program  terminates.  The  "CLPCCM . CMC"  file  contains  the  necessary 
information  needed  to  start  up  the  user  requested  CLPARS  command. 
It  also  lets  the  HELOLP  command  file  "know"  which  CLPARS  command 
has  been  executed.  If  the  CLPARS  "logout"  command  (EYECLP)  was 
requested  by  the  user,  the  "EYECLP. CMC"  file  is  invoked.  Cnee 
"EYECLP.CMD"  is  finished,  the  HELOLP  command  file  stops  its  own 
execution . 

The  following  two  pages  illustrate  the  0LPAR5  Command  Input 
Processor,  "login",  and  "logout"  functions,  and  relationships 
between  RSX  command  files  and  CLPARS  programs  implementing  these 
functions . 
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A 


HELGLP  COMMAND  FILE  ( HELCLF .  Ct-.D  ) 


1.  invoke  CLPDIR. CMC 

2.  query  user  for  login  name 

3.  call  CMINIT  program 

repeat 

4.  call  CIP  program 

5.  invoke  CLPCCK.CMD 

until  (user  types  "EYECLP") 


CLPDIR  COMMAND  FILE  (CLPDIR . CMC) 
!  locate  CLPARS  system  directory 


CMINIT  program 


1  .  ask  user  for  terminal  type 
2.  initialize  terminal  screen 
parameters  and  CLPARS 
directory  string  in  user 
CM  file. 


COMMAND  INPUT  PRCCESSOR  program 


repeat 

1 .  prompt  user  for  CLPARS 
command 

until  (command  is  valid) 

2.  create  CLPCCM.CMD 


OLPCCH  CCMM \ND  FILE  (OLPCCM.CMD) 


!  initiate  user  requested  CLPARS  i 
!  command  I 


BYECLP  CCMMAND  FILE  (EYECLP.CMD) 
!  clean  up  loose  ends 


OLPARS  Command  Input  Processor,  "login",  and  "logout" 
functions  Summary 
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OLPARS  system 
directory 


TERMINALS .TXT 

»« 


TEK4C51 .TXT 

IMLAC.TXT 

TEK4014.TXT 


i  PROGRAMS.TXT 


iBYECLP.CMD 


Olpars  Commands 


< 


Any  RSX11M  directory 


!  HELGLP.CMD 

:  //////////////////////// 

-  CLPDIR.CMD 

!//////////////////////// 

i  Login  Name  Validation 
!  and  User  Directory 
i  Information  - 


!  \ 

!  \ 

- >  CMINIT 

:  / 

:  / 


i 

i 

i 

i 

- - >  CIP 

! 

i 

i 


< 


**  contains 
strings 

I 

IMLAC 

TEK4014 

TEK4C51 


> 


OLPARS  user 
directory 


>!  CM. CLP 


> |  OLPCCM.CMD  ! 


Relationships  between  RSX  command  files  and 
OLPARS  programs  implementing  the  Command 
Input  Processor  (CIP),  "login",  and  "logout" 
functions 
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CLPARS  RSX-11N  SYSTEM  DEPENDENT  FILES 


E.  1  T.ie  CLPARS  Directory 

Each  CLPARS  program  including  the  CIP,  resides  as  a  segment 
task  (  .TSK)  file  in  the  CLPARS  directory.  There  are  also  several 
purpose  files  which  reside  in  this  directory.  These  include  the 
CLPARS  option  file  (OPTION. CLP)  the  CLPARS  option  text  file 
(OPTIGN.TXT),  the  CLPARS  terminal  screen  coordinate  files 
(including  TERMINALS.TXT),  and  the  OLPARS  program  dictionary 
( PROGRAMS.TXT ) .  These  files  are  described  in  the  following 
sections . 

B . 1 .  1  OLPARS  Option  File 

The  option  file  contains  the  names  of  all  OLPARS  commands,  an 
associated  option  number,  and  a  possible  list  of  other  options 
(programs)  that  are  associated  with  a  given  option.  Under  RSX-11M, 
the  option  file  has  the  name  "OPTION. OLP"  and  is  a  fixed  length 
record  (block  I/O)  file. 

The  first  word  of  the  first  record  of  the  option  file  contains 
the  number  of  options  in  the  file.  The  next  portion  of  the  file 
contains  the  option  name  -  option  number  associations.  This  part 
file  has  the  option  names  in  alphabetical  order.  The  next 
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section  holds  the  option  numbers  and  option  list  pointers.  The 
option  numbers  are  sorted  into  ascending  numerical  order.  The  last 
section  contains  the  option  list,  which  is  nothing  more  than  s  list 
of  pointers  to  the  option  names  in  the  option  name-option  number 
section.  The  first  number  in  the  option  list  is  actually  the 
number  of  options  contained  in  the  list.  (See  Figure  E-1 ) . 

The  two  CLPARS  programs  that  access  this  file  are  SETCPT  and 
GETCFT .  SETOPT  looks  through  the  option  name-option  number  section 
for  an  option  name.  It  returns  to  its  calling  program  the  option 
number  of  the  option  name  for  which  it  was  looking.  If  SETCFT 
cannot  find  the  given  option  name,  it  will  return  ’ ANYTHING » s 
option  number.  C-ETOFT  scans  through  the  option  number-option  list 
pointer  section  for  an  option  number.  It  will  return  to  its 
calling  program  the  names  of  the  options  pointed  to  by  the  elements 
of  the  option  list  section.  Note  that  an  option  may  have  more  than 
one  option  list  associated  with  it,  i.e.,  multiple  menus  (see 
Figure  B-1,  option  #20).  It  is  also  possible  that  an  option  does 
not  have  an  option  list  (e.g.,  option  #90  in  Figure  B-1). 

B.1.2  CLPARS  Option  Text  File 

A  system  dependent  program  called  KAKOPT  creates  the  options 
file  (CPTION.CLP)  from  a  source  text  file  (OPTICN.TXT)  containing 
each  CLPARS  command  with  its  option  number  and  option  list.  This 
program  should  be  used  only  by  CLPARS  programmer s/maintainers  to 
create  the  proper  option  file  (see  Appendix  G  for  usage  of  MAKOPT). 
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CLPARS  CPTICN  FILE 


OPTION  FILE 
RECORD  NO. 


1 

9 

»  of 

options  ! 

1 

2 

A  BCD 

10 

* 

1 

1 

1 

3 

AKLMD 

20 

1 

1 

1 

1 

4 

DEFG 

40 

1 

1 

1 

1 

5 

EFG 

100 

1 

!  Option  name  - 

!  Option  number 

6 

FDX 

50 

i  Section 

1 

7 

LVD 

60 

1 

!  (header) 

1 

8 

STU 

70 

1 

1 

1 

1 

9 

VDA 

80 

1 

1 

1 

1 

10 

ZBE 

90 

1 

1 

1 

1 

1 1 

10 

20 

1 

1 

12 

20 

21 

22 

23  ! 

13 

40 

24 

I 

» 

14 

50 

25 

!  Option  number  - 

!  Option  list  pointer 

15 

60 

26 

|  Section 

16 

70 

27 

!  (logical  entry) 

17 

80 

28 

1 

1 

18 

90 

-1 

1 

1 

19 

100 

29 

1 

1 

i 

20 

4 

4 

5 

3  8 

21 

2 

7 

4 

1 

1 

22 

2 

8 

9 

1 

1 

23 

1 

6 

i  Option  list 

24 

1 

8 

!  Section 

25 

1 

5 

1 

1 

26 

3 

8 

4 

6  !  (logical  entry) 

27 

2 

4 

2 

1 

1 

28 

2 

3 

5 

1 

J 

29 

1 

8 

1 

1 

Figure  B-1  OLPARS  Option  File  (OPTION. CLP) 
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The  format  of  the  source  text  is  as  follows: 

PROGRAM  NAME  :  OPTION  #  :  MENU  i!  :  OPTION  1  ...  OPTIC!.  15 

The  program  name  refers  to  an  CLPARS  command .  The  maximum 
length  of  a  program  name  allowed  in  the  CFTION.CLP  file  is  10 
characters.  The  option  number  is  an  arbitrarily  assigned  unique 
number . 

Cnee  the  option  number  is  assigned  to  a  program,  that  program 
should  always  retain  the  same  option  number.  The  reason  for  this 
is  that  user  files  (logic  trees,  for  instance)  retain  the  option 
number  (of  the  program  that  created  them)  as  data.  If  the  option 
number  of  an  existing  OLPARS  program  were  changed,  all  the  user 
files  containing  that  option  number  would  now  have  incorrect  option 
numbers . 

The  menu  number  represents  the  different  possible  menus 
(option  lists)  that  a  single  CLPARS  command  might  display.  The 
menu  numbers  need  not  be  in  order,  but  they  must  be  continuous 
(that  is,  if  there  are  four  different  menus,  the  menu  numbers  used 
must  be  1 ,  2,  3  and  4 )  . 

The  option  list  is  a  set  of  "other"  CLPARS  commands  that  may 
be  used  after  "PROGRAM  NAME"  has  completed  it  computations.  The 
command  names  are  separated  by  spaces.  The  last  option  should  have 
a  "slash"(/)  following  it.  The  slash  must  be  separated  from  the 
last  option  by  at  least  one  space  (see  Figure  E-2). 
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This  example  format 
was  used  when  producing 


the  option  file 
in  Figure  E-1 . 


ABCD 

10 

1 

AKLMD 

20 

1 

AKLMD 

20 

2 

AKLMD 

20 

3 

DEFG 

HO 

1 

EFG 

100 

1 

FDX 

50 

1 

LVD 

60 

1 

STU 

70 

1 

VDA 

80 

1 

2BD 

90 

1 

found 


DEFG  EFG  AKLMD  STU  / 
LUD  DEFG  /  . 

STU  VDA  / 

FEX  / 

STU  / 

STU  / 

EFG  / 

STU  DEFG  FDX  / 

DEFG  ABCD  / 

AKLMD  EFG  / 

/ 


Figure  B-2  OLPARS  Option  Source  Text  File 
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The  maximum  number  of  options  allowec  in  the  option  list  is  15. 

A  semicolon  found  in  column  one  of  any  text  record  will  denote 
a  comment  line  (a  line  to  be  ignored  by  the  MAKOFT  program).  Blank 
lines  are  not  allowed  in  the  file  (they  cause  MAKOFT  to  quit 
reading  the  file).  The  option  list  may  extend  over  several  lines. 
If  this  occurs,  comments  MJST  NOT  separate  the  lines. 

In  the  example  given  (Figure  E-1 ) ,  the  programs  names  are  in 
alphabetical  order.  This  is  necessary  to  create  a  proper  option 
list  file. 

In  the  current  'CPTIGN.TXT'  file  a  few  of  the  program  names 
have  been  commented  out  because  of  space  considerations  within  the 
MAKOFT  program.  Those  that  have  been  commented  out  will  name 
'ANYTHING'  as  their  option  list  (see  SETOFT  in  section  B2).  In 
fact,  any  program  (with  a  name  in  the  'OFTION.TXT'  file)  that  does 
not  alter  the  mathematical  projection  of  a  data  set,  or  the  actual 
vectors  within  the  current  data  set  may  be  commented  cut. 

B. 1.2.1  Future  Option  File  Maintenance 

A  modification  to  the  current  option  file  scheme  would  give 
CLPARS  maintenance  people  better  control  over  the  consistency  of 
the  "ANYTHING"  command  found  in  CLPARS.  A  description  of  how  the 
"ANYTHING"  command  works  is  now  in  order. 
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Currently,  ANYTHING  is  a  very  simple  pregram.  It  simply  reads 
a  text  file  (ANYTHING.TXT)  and  prints  it  out  to  the  user’s 
terminal.  The  file  contains  a  list  of  all  the  CLPARS  programs  and 
the  category  in  which  they  reside.  This  means  that  whenever  a  new 
command  is  added  to  CLPARS,  both  the  CPTICI1.TXT  file  ar.d 
ANYTHING . TXT  file  must  be  modified.  This  could  cause  consistency 
problems  for  an  CLPARS  maintenance  person  if  (s)he  forget  (heaven 
forbid,  not  me)  to  alter  both  files.  To  subvert  this  problem, 
changes  would  have  to  be  made  to  the  CPTION.TXT  file  (thus,  the 
GFTICN.GLP  file),  the  KAKOPT  program  and  the  ANYTHING  program. 

1.  To  the  CPTION.TXT  file,  a  category  code  would  be  added  to 
each  program  record.  Note,  all  commands  would  have  to  be 
entered  into  the  CPTION.TXT  file  (not  "commented"  out  like 
some  are  now  to  save  array  space  in  KAKOPT). 

2.  MAKOPT  would  have  to  be  changed  to  handle  the  category  code. 

To  save  space  in  the  program,  a  temporary  file  would  have  to 

i 

be  created  for  option  list  storage  (which  means  a  "re-think"  \ 

on  the  whole  MAKCPT  algorithm). 

3.  The  ANYTHING  program  would  be  re-written  to  read  the  new 
OPTION. CLP  file  created  by  MAKOPT  (The  ANYTHING.TXT  file  is 
no  longer  used).  It  would  then  organize  the  program  names 
according  to  their  category  code,  before  printing  cut  the 
results  to  the  terminal. 
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For  an  alternative  to  the  above,  KAKCFT  could  co  all  the 
categorization  work  and  add  another  list  to  the  CFTICN.GLP  file 
with  all  the  programs  placed  within  their  own  categories.  Then 
ANYTHING  would  be  less  complicated  than  previously  mentioned.  This 
modification  (on  system  dependent  programs)  is  only  suggested  for 
easier  maintenance  of  CLPARS. 

B.  1.3  CLPARS  Terminal  Screen  Coordinate  Files 

The  terminal  screen  parameters  (see  section  5.1. A)  are  stored 
in  individual  text  files  found  in  the  CLPAR  system  directory.  The 
name  of  these  files  are  stored  in  the  file  TERKINALS.TXT,  also 
found  in  the  same  directory.  When  a  user  ’’logs"  into  CLPARS  (see 
Appendix  A),  the  TERMINALS . TXT  file  is  displayed  at  the  user’s 
terminal.  They,  in  turn,  choose  one  of  the  terminal  names  (file 
names,  without  the  filename  type  or  extension  name  added)  from  the 
list  displayed.  The  file  type,  ".TXT",  is  attached  to  the  terminal 
name  chosen.  The  resultant  name  is  used  to  access  the  screen 
parameters  file.  The  screen  parameters  are  stored  in  the  user's 
Communications  file.  The  following  text  shows  an  example  of  the 
contents  of  a  TERMINALS.TXT  file  and  the  contents  of  a  screen 
parameters  file. 
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Example  Contents  of  TERKINALS.TXT 

tek4C14a  -  Tektronix  4014  with  smallest  size  characters 
tek4014b  -  Tektronix  4014  with  next  to  smallest  characters 

tek4G14c  -  Tektronix  4014  with  next  to  largest  characters 

tek4C51  -  Tektronix  4051 

IKLAC  -  Tektronix  compatabil ity  mode  only 


Example  Contents  of  TEK4C51.TXT 


640 

Ws 

- 

no.  of  display  units  in  screen  width 

480 

Hs 

- 

no.  of  display  units  in  screen  height 

460 

Wd 

- 

no.  of  display  units  in  display  width 

391 

Hd 

- 

no.  of  display  units  in  display  height 

S 

Wc 

- 

no.  of  display  units  in  char,  width 

14 

He 

- 

no.  of  display  units  in  char,  height 

88 

a 

- 

x  coord,  of  lwr.  left  corner  of  display 

75 

b 

- 

y  coord,  of  lwr.  left  corner  of  display 

548 

c 

- 

x  coord,  of  upr.  rt.  corner  of  display 

466 

d 

- 

y  coord,  of  upr.  rt.  corner  of  display 

28 

MrW 

- 

number  of  rows  in  a  cluster  plot  grid 

40 

Ncl 

- 

number  of  cols,  in  a  cluster  plot  grid 

74 

LcH 

- 

number  of  characters  in  a  screen  line 

0 

Not 

used  ,  yet 

133 

e 

- 

x  coord,  of  left  side  of  1  space  base  line 

96 

f 

- 

y  coord,  of  lowest  1  space  base  line 

503 

g 

- 

x  coord,  of  right  side  of  1  space  base  line 

10 

Nc 

- 

max.  no.  of  classes  on  1  sp.  macro  plot 

28 

Cs 

- 

distance  between  macro  base  lines 

B.1.4  CLPARS  Program  Dictionary 


The  CLPARS  program  dictionary  (PR0GRAMS.TXT)  is  a  simple  text 
listing  of  all  the  CLPARS  commands,  kept  in  alphabetical  order. 
The  Command  Input  Processor  ( CIP)  uses  this  list  to  verify  whether 
or  not  the  CLPARS  user  has  entered  a  legitimate  CLFARS  command. 
The  file  may  contain  same  line  comments.  There  must  be  at  least 
one  space  between  the  program  name  and  the  comment. 
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Example  of  a  Frogram  Dictionary: 


ANYTHING 

BYECLP 

CRAKDTS 

DDATANOD 


This  programs  displays  the  ANYTHING.TXT  file 
program  used  to  exit  CLEARS 
create  a  random  data  set 
delete  a  node  from  a  data  tree 


B.2  The  User’s  Directory 

Each  CL PARS  user  must  have  an  ESX-1 IK  directory  to  store  local 
CLPARS  user  files.  These  include  fixed  and  variable  files, 
temporary  sequential  files  containing  information  to  be  sent  to  a 
line  printer,  and  ASCII  data  files.  The  fixed  and  variable  files 
have  been  discussed  in  great  detail  in  earlier  sections.  The 
sequential  files  for  line  printer  output  are  created  and  opened  by 
a  system  dependent  program  OPENS.  They  are  written  into  by  the 
routines  that  produce  line  printer  output.  An  operating  system 
utility  (PIP,  on  RSX-11M)  will  cause  the  file  to  be  printed  and 
then  deleted  (depending  on  local  operating  system  configuration) 
from  the  user's  directory. 
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The  ASCII  data  files  are  used  during  the  process  of  reading  cr 
writing  data  to  files.  In  order  to  create  an  CLPARS  data  tree  from 
data  within  a  file  in  the  user's  directory,  the  data  must  be  in 
CL  PARS  data  file  input  format  (see  the  description  for  FILEI.'i  in 
the  CLPARS  User's  Manual).  Similarly,  the  data  file  created  by 
FILECUT  (the  CLPARS  data  set  dumping  routine)  is  put  into  the 
OLPARS  data  output  format  (see  FILEOUT  in  the  CLPARS  User's 
Manual).  The  file  created  by  FILECUT  can  be  used  as  input  tc 
FILEIN.  Two  of  the  user  files  which  are  system  dependent  are  the 
File  Code  Table  (FCT.CLP)  and  History  (HS.CLP)  file.  The  FCT  is 
described  in  the  next  section.  The  History  file  is  described  in 
Appendix  E,  along  with  the  CLPARS  instrumentation  package. 
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E.2.1  File  Code  Table 

The  CLPARS  File  Cede  Table  (FCT)  contains  the  system  names  of 
the  fixed  and  variable  files  that  belong  to  an  CLEARS  user.  The 
system  names  of  the  fixed  files  reside  ir.  the  first  1C  entries  of 
the  FCT  as  fellows: 


File 

Entry 

(File  Code) 

RSX-11M  File 

Communications 

1 

CM. CLP 

Tree  List 

2 

TL. CLP 

Logic  List 

3 

LL.CLP 

Display  Information 

4 

DI.CLP 

Display  Value 

c. 

DV.CLP 

Projection  Vector 

6 

PV. CLP 

Scratch  1 

T 

SI. CLP 

Saved  Vector 

8 

SV.CLP 

Saved  Transformation 

Matrix 

9 

SM.CLP 

History 

10 

HS.CLF 

Under  RSX-11M,  the  FCT  will  be  a  direct  access  file  (using 
CLPARS  "block"  I/O)  with  a  record  size  of  8  words.  The  first 
record,  the  header,  will  contain  a  pointer  to  the  next  available 
entry  to  be  filled  (first  entry  in  the  free  list  link),  the  number 
of  filled  entries,  a  pointer  to  the  last  entry  in  the  free  list 
link,  and  a  pointer  to  the  last  entry  in  the  table.  These  four 
integers  will  be  found  in  the  first  four  words  of  the  first  record 
( see  Figure  E-3 ) . 
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FILE  CCDE  TABLE  ( FCT ) 


head  er 


entry 


next  available  entry  =  16 
number  of  filled  entries  =  14 
last  entry  in  free  list  link 
last  entry  ■*  n  file  code  table 


1 

0 

a 

0 

3 

0 

4 

0 

5 

0 

6 

0 

7 

0 

8 

0 

9 

0 

10 

0 

1  1 

0 

12 

0 

13 

18 

14 

13 

15 

0 

16 

14 

17 

0 

18 

19 

19 

-1 

CM. CLP 
TL.CLP 
LL. CLP 
DI.CLP 
DV. CLP 
PV.CLP 
SI. CLP 
SV. CLP 
SM.CLP 
HS. CLP 

LOGIC23 1 . OLI 
LCGIC231 .CLV 
TWENTYCN.OLV 
TWENTYON. OLI 
ALBERTAS.CTI 


ALBERTAS. CTV 


Figure  E-3  File  Code  Table  (file) 
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The  rest  of  the  file  contains  the  RSX-1  It-;  file  name  recorcs 
that  CLPARS  needs  to  access  the  user's  fixed  and  variable  files.  A 
file  name  record  consists  of  a  free  list  link  pointer  and  a  file 
name.  In  the  first  word  of  the  file  name  record  resides  the  free 
list  link  pointer.  The  last  seven  words  contain  the  file  name, 
including  a  null  character  (zero  in  CLPARS).  When  the  free  list 
pointer  is  zero,  the  file  name  portion  of  the  record  contains  the 
file  name  of  an  existing  RSX-1 1M  file.  When  the  pointer  is 
non-zero,  the  file  name  record  resides  in  the  free  list  of  file 
name  records,  i.e.,  the  file  name  record  is  available  for  use  by 
OLPARS.  In  Figure  £-3  entries  13  and  14  are  in  the  free  list  even 
though  they  have  an  old  file  name  left  in  the  file  name  portion  of 
the  record. 

The  "free  list"  is  a  linked  chain  of  file  name  records.  The 
head  of  the  chain  is  found  in  the  first  record  of  the  FCT.  It  is 
called  the  next  available  entry  pointer  (see  abcve) . 

The  last  link  in  the  free  list  chain  contains  a  -1,  an  invalid 
link  value.  If  the  File  Code  Table  is  full,  both  the  next 
available  entry  pointer  and  the  last  entry  in  the  free  list  link 
equal  zero.  If  the  next  available  entry  and  the  last  entry  in  the 
free  list  link  are  equal,  but  not  zero,  then  there  is  one  free 
entry  left  in  the  File  Code  Table.  This  entry's  link  will  contain 
the  -1  mentioned  above. 
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The  size  of  the  File  Cede  Table  will  determine  the  number  of 
trees  an  CLPARS  user  may  have  within  his  CLPAKS  directory.  The 
size  of  a  user's  FCT  can  be  determined  by  an  CLPARS  installation 
manager  when  (s)he  creates  a  user's  directory.  It  may  also  be 
extended  at  a  later  date. 
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STEFS  TC  TAKE  III  EXPANDING  CLPARS  UNDER  RSX-11K 


c  Adding  a  ccn.mand  to  CLPARS: 


1.  Put  the  name  of  the  command  in  the  program  dictionary 
(can  use  EDI  editor  utility)  in  alphabetical  order.  The 
program  directory  is  in  the  CLPARS  directory. 


2.  Add  the  appropriate  entries  to  the  CPTICti.TXT  file 
(using  EDI)  in  the  CLPARS  directory  and  execute  the 
program  MAKOPT  for  a  new  options  file. 


3.  Create  a  Help  file  for  the  command  within  the  help 
directory  and  add  the  command  name  to  the  help 
dictionary( see  Appendix  D) . 


o  Adding  a  user  to  CLPARS: 


1.  Create  the  user’s  "system"  directory  with  the  UFC 
utility  (provided  by  DEC  on  RSX-11K). 


2.  Add  the  user's  "login"  identification  along  with  the  User 
Identification  Code  (UIC)  of  his/her  newly  created 
directory  to  the  HELOLP.CMD  command  file,  found  in  the 
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CLPARS  directory  (use  ECI). 

3.  Use  the  GEN  prog  rammer ' s  aid  to  create  the  fixed  files  in 
a  user’s  directory.  (GEN  can  also  be  used  to  expand  the 
FCT  table  of  an  "old"  CLPARS  user.) 


APPENDIX  D 


OLPARS  "HELP"  FUNCTION 


The  help  file  gives  the  user  information,  at  his/her  terminal, 
about  an  CLPARS  subject  or  command.  The  "HELP"  pregram  is  system 
dependent . 

The  "HELP"  program  prompts  the  user  for  input.  The  user  may 
type  in  the  name  of  an  CLPARS  subject  or  command  for  which  (s)he 
desires  information  (help).  Initial  characters  (substrings)  cf  the 
command  or  subject  name  may  also  be  typed.  The  user  may  type  "ALL" 
for  a  list  of  available  help  files. 

All  the  text,  used  to  describe  a  specific  CLPARS  subject  or 
command,  is  referred  to  as  a  "HELP"  file.  The  character  string 
typed  by  a  user,  in  response  to  the  "HELP"  program  prompt,  will 
identify  a  "HELP"  file  to  be  accessed.  All  "HELP"  files  exist  in 
the  same  directory  and  have  the  same  RSX-1 1M  filename  extension 
(e.g.  ".HLP"). 

In  addition  to  accessing  the  "HELP"  files,  the  "HELF"  program 
accesses  a  file  called  "HELP.TXT"  (the  help  dictionary)  ,  and  a  file 
called  "HELPDIR.TXT."  "HELP.TXT"  contains  an  alphabetical  listing 
of  subjects  and  commands  for  which  help  is  available. 
"HELPDIR.TXT"  contains  the  device  name  and  directory  string  needed 
to  locate  the  "HELP"  files.  It  also  contains  the  RSX-1 1M  filename 
extension  for  the  "HELP"  files.  The  "HELP"  program  uses  the 
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information  in  "HELPCIR.TXT"  to  construct  the  complete  F.SX-1  1M 
filename  for  the  "HELP"  file  to  be  accessed.  The  filenames 
" HELP.TXT ”  and  "HELPDIR.TXT"  are  "built-in"  to  the  "HELP"  program. 
If  for  some  reason  one  wanted  to  change  these  names,  the  "HELP" 
program  would  have  to  be  modified.  These  two  files  reside  in  the 
GLPAR  system  directory,  where  the  OLPARS  tasks  are  located. 

The  existence  of  the  "HELP.TXT"  file  makes  it  possible  for  the 
user  to  type  a  substring  of  a  subject  or  command  for  which  help  is 
being  requested.  The  "HELP"  program  searches  the  "HELP.TXT"  file 
for  the  user-typed  character  string.  If  the  character  string  is 
found,  the  complete  subject  or  command  name  is  gotten  from 
"HELP.TXT"  and  is  used  to  construct  the  "HELP"  file  name.  Thus  it 
is  net  necessary  for  the  user  to  type  the  entire  name.  The 
user-typed  character  string  should,  however,  be  sufficiently  long 
to  be  unique  within  "HELP.TXT."  If  the  character  string  is  not 
unique,  help  will  be  provided  for  the  first  subject  or  command  in 
"HELP.TXT"  whose  initial  characters  match  the  user-typed  character 
string.  If  the  "HELP"  program  does  not  find  the  user-typed 
character  string  in  "HELP.TXT,"  the  character  string  itself  will  be 
used  as  the  "HELP"  filename  and  an  attempt  will  be  made  to  access 
the  help  file.  Thus,  there  may  be  help  available  for  subjects  and 
commands  which  do  not  appear  in  "HELP.TXT."  If  the  user  wishes  to 
access  these  help  files,  (s)he  must  type  the  complete  "HELP" 
filename  (not  including  the  filename  extension). 


to 
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One  special  help  file,  the  "ALL"  help  file,  exists  tc  provide 
the  user  with  a  list  cf  subjects  and  commands  for  which  help  is 
available.  The  format  of  the  "ALL"  help  file  may  vary.  Subjects 
and  commands  may  be  listed  together  or  separately,  or 
alphabetically  or  categorically,  depending  on  the  system  managcr"s 
preference.  Cne-line  definitions  for  subjects  and  commands  may  be 
provided  (e.g.  since  RSX-1 IK  filenames  are  limited  to  nine 
characters,  and  it  is  difficult  to  describe  a  subject  using  only 
nine  characters,  "HELP"  filenames  pertaining  to  CLPARS  subjects  may 
not  have  meaning  to  a  user.  Therefore,  a  one-line  description 
could  accompany  the  subject  name  in  the  "ALL"  help  file). 

The  "HELP"  function  is  designed  to  be  flexible.  The  format  of 
the  help  files  (including  the  "ALL"  help  file)  may  vary  and  can  be 
designated  by  the  system  manager.  "HELP"  files  may  be  added  to  the 
help  directory,  at  any  time,  through  the  use  of  a  text  editor.  The 
system  manager  should  obtain  user  feedback  to  determine  which 
OLPARS  subjects  should  have  "HELP"  files,  and  to  decide  upon  a 
format  for  those  files. 
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An  example  of  filename  construction  using  "HELP.TXT" 
and  " HELPDIR.TXT . " 

HELP.TXT  contains  the  following  help  filenames: 

APPEND 

CDEFAL'LT 

DSCRMEAS 

FILEIN 

L2EIGV 

HELPDIR.TXT  contains  the  character  string: 

DEC : [3 1 3 »  46 ] . HLP  <  ANY  USEFUL  COMMENTS  MAY  OCCUR  HERE  > 


The  user  types  the  substring  'DSC*  in  response  to  the 
"HELP"  command  prompt.  The  "HELP"  program  searches  the 
"HELP.TXT"  file  to  find  the  string  'DSC'.  "HELP"  retrieves 
the  "HELP.TXT"  entry  for  'DSCRMEAS'.  Next,  it  reads  the 
directory  string  from  "HELPDIR.TXT"  (a  right  bracket 
indicates  the  end  of  the  directory  string)  .  It  appends  the 
name  'DSCRMEAS'  to  the  directory  string.  Lastly,  it  reads 
the  filename  extension  ".HLP"  from  "HELPDIR.TXT"  and 
appends  this  to  the  directory-filename  character  string. 
The  result  is  the  complete  filename: 

DBG: [313.463DSCRMEAS.HLP 

This  "HELP"  file  is  printed  at  the  user's  terminal. 
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The  instrumentation  package  is  used  as  a  debugging  tccl 
( instrument )  for  CLPARS  programmers.  The  package  consists  of  a 
series  of  subprograms  that  will  enable  a  programmer  tc  keep  track 
of  the  entry  and  exit  of  a  program,  along  with  the  values  cf 
specific  variables  within  the  program. 

E.1  Philosophy 

The  programming  staff  at  PAR  has  already  had  experience  with 
the  uses  of  an  instrumentation  package  within  a  large  conglomerate 
of  programs.  It  was  found  that  the  instrumentation  package  was  a 
very  useful  tool  for  debugging  FORTRAN  programs.  Previous 
packages,  however,  did  not  make  use  of  prior  knowledge  of  a 
program's  execution  (i.e.,  the  program's  history).  This  meant  that 
when  the  instrumentation  was  enabled,  every  program  (in  the  larger 
system  of  programs)  was  traced,  even  if  the  program  was  fully 
tested  and  debugged.  In  certain  cases,  this  also  meant  that  a 
large  amount  of  paper  was  used  to  print  out  the  instrumentation 
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With  this  in  mind,  we  thought  it  would  be  useful  for  a 
program,  that  has  worked  successfully  for  periods  of  time,  to  net 
participate  in  the  instrumentation  tracing  while  the  package  was 
enabled.  To  do  this,  each  program's  "history"  would  have  to  be 
monitored  . 

In  the  OLPARS  instrumentation  package,  all  programs  are 
initially  assumed  to  be  "successful"  programs.  Since  there  is  no 
"history"  for  new  programs,  this  assumption  must  be  made.  However, 
if  that  program  fails  in  its  execution  (i.e.,  it  is  not  a 
successful  program)  ,  its  "history"  will  now  indicate  this  fact. 
Further  usages  of  the  program  will  cause  tracing  to  be  seen  (only 
while  instrumentation  is  enabled)  until  the  program  has  completed 
successfully  some  arbitrary  number  of  times.  Cnee  the  program 
completes  this  arbitrary  number  of  successful  executions,  the 
tracing  will  again  disappear. 

With  this  method  of  program  tracing,  a  programmer  will  not 
need  to  worry  about  programs  that  have  good  "histories".  It  will 
also  keep  the  tracing  to  a  minimum,  thus,  focusing  a  programmer's 
attention  on  the  problem  areas  of  a  program.  The  programmer  will 
not  have  to  wade  through  piles  of  program  tracing  (a  definite 
savings  since  paper  is  an  expensive  commodity). 
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£.2  Using  the  Instrumentation  Fackage 

Tc  use  the  instrumentation  package  properly,  a  program  should 
make  reference  to  a  few  of  the  instrumentation  programs  in  the 
following  manner. 

In  the  "main"  program,  before  any  disk  files  are  cpenec,*  a 
single  call  should  be  made  to  the  instrumentation  initialization 
routine  (It.'SINI).  This  routine  is  used  to  enable  or  disable  the 
instrumentation  package  for  the  current  operation  of  the  "main" 
program,  initialize  various  instrumentation  variables,  and  open  two 
instrumentation  information  files.  Before  the  "main"  program 
exits,  it  should  make  a  call  to  INSRET. 

All  subprograms**  of  the  "main"  program  should  make  calls  tc 
the  instrumentation  subroutines  *  IliSPGM*  and  'INSRET’  after  entry 
and  upon  exit  to  the  subprogram,  respectively.  When  tt.° 
instrumentation  packge  is  enabled,  these  two  programs  print  out 
subprogram  entrance  and  exit  messages  on  the  instrumentation 
listing,  control  the  debug  printout  indentation,  and  keep  track  of 
the  "history"  of  each  subprogram. 


*  The  reason  for  calling  'INSINI'  before  files  are  opened  is 
explained  later  in  "Some  Notes  about  Instrumentation  Fackage 
use  on  RSX-1  IF! . 

**  There  are  a  few  programs  that  cannot  make  calls  to  the 
instrumentation  package  (because  they  are  used  by  the 

instrumentation  package;  hence,  infinite  recursion  would 

occur )  . 
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The  above-mentioned  steps  are  the  only  mandatory  procedures  to 
be  adhered  to  for  proper  usage  of  the  instrumentation  package.  The 
variable-printout  (dump)  calls  to  the  instrumentation  package  may¬ 
be  done  at  any  time  after  the  initialization  routine  (IN SIM)  is 
called  . 

E. 3  The  "History"  aspect  of  the  CLPARS  Instrumentation  Fackage 

Throughout  the  source  code  of  the  instrumentation  package 
there  is  mentioned  the  concept  of  a  program's  "history."  The  stored 
information  necessary  to  keep  tally  of  a  program's  successful 
completion  is  called  a  program's  "history." 

Each  CLPARS  program  (not  found  in  the  instrumentation  package) 
will  have  its  own  history  record  which  will  be  found  in  an  CLPARS 
"history"  file.*  The  history  record  will  contain  the  name  of  the 
program,  the  length  of  that  name,  a  tally  requesting  the  number  of 
times  this  program  is  to  report  its  usage  after  failure,  and  an 
overflow  link  record  pointer  (see  Figure  E-1 ) . 

The  "history"  file  is  initially  created  by  'GEN',  the  CLPARS 
"fixed"  files  generating  program.  The  header  portion  of  the 
"history"  file  contains  the  record  number  of  the  first  available 
overflow  record  in  the  file  (see  Figure  E-2). 


The  history  file  is  one  of  the  CLPARS  user's  "fixed"  files. 
Under  the  RSX-1 1M  operating  system,  the  file  is  named  'HS.CLP'. 
'.(ithin  CLPARS  programs,  the  history  file  is  referred  to  through 
its  two  letter  mneumcnic,  'HS*. 
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GLPARS  HISTORY  FILE  RECCED 


1 

1 

!-  .5  rel-i 


1  1 

1  i 

i  Cverflow  | 

i  1 

1  1 

1  Dame  ! 

!  Link  ! 

Tally  !  ! 

Name  ! 

!  Pointer  ! 

i  1 

1  1 

!  Length  ! 

1  l 

1  1 

I—  1  rel  - ! 

- 2  r el s - ! 

*  Real  element;  under  RSX-1 1M  a  'rel'  is  composed 
of  two-16  bit  words 


Figure  E-1  OLPARS  History  file  record 
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CLEARS  HISTORY  FILE 


First  Available  overflow  record 
number  (points  to  end  of  file) 


HISTORY  RECORD 


HISTORY  RECORD 


HISTORY  RECORD 


OVERFLOW  HISTORY  RECORD 


Head  er 


Primary 

Region 


Overflow 

Region 


Figure  E-2 


OLPARS  History  file 
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Initially,  the  "history"  records  have  their  link  pointer, 
tally  and  name  length  set  to  zero. 

The  "history"  file  can  be  considered  a  "hash"-  table.  A 
program’s  "history"  record  is  found  by  "hashing"  the  name  of  the 
program,  using  the  resultant  number  as  a  pointer  into  the  history 
file. 


If  two  program  names  "hash"  to  the  same  history  file  record 
number  (called  colliding),  then  the  link  pointer  of  that  record 
number  is  set  to  point  to  a  record  in  the  overflew  area.  This 
overflew  record  becomes  the  history  record  of  the  second  program. 
Another  collision  to  the  same  record  number  by  another  program 
would  result  in  the  link  pointer  of  the  first  colliding  program  to 
point  to  a  new  overflow  record.  This  process  would  be  repeated  for 
each  new  "hash"  collision  (see  Figure  E-3). 

The  "hashing"  function  being  used  is  a  slight  modification  of 
the  division  remainder  algorithm  found  in  most  simple  hashing 
routines.  To  keep  collisions  to  a  minimum  (thus,  file  access), 
this  algorithm  requires  that  the  number  of  entries  in  the  table  be 
prime.  (Further  details  of  the  algorithm  can  be  found  in  the 
OLPARS  Software  Reference  Manual  under  the  program  name  "HASH".) 


"Hashing"  refers  to  the  concept  of  mathematically  combining  the 
internal  representation  of  a  character  string  to  create  a 
single  number.  The  resulting  number  is  usually  used  as  a 
pointer  into  some  table. 
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Programs  in  existence 
with  history  records 
are  A, B, C, C, E,  and  F 
where : 

Hash(A)  =  Hash(E) 
Hash(C)  =  Hash(D) 
Hash(C)  =  Hash ( E  ) 

That  is,  B  collides 
with  A,  while  C  and  E 
co-llide  with  C. 


Figure  E-3  Example  of  link  pointer  usage  in 
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The  tally  portion  of  the  history  record  is  used  to  decide- 
whether  or  net  any  debug  information  is  to  be  printed  when  the 
instrumentation  package  is  enabled. 

E.L  The  Life  of  an  CLFARS  "history"  Record 

khen  the  instrumentation  package  is  enabled,  the  following 
steps  occur  for  the  subprogram  "EXAMFL". 

The  subprogram  "EXAMFL"  is  currently  being  executed.  Its  name 
is  "hashed"  and  the  resulting  record  number  points  to  the  history- 
record  for  "EXAMPL".  The  record  is  read  from  the  "history"  file. 
It  is  found  that  the  name  length  of  the  record  is  zero.  Therefore, 
this  is  the  first  time  "EXAMPL"  has  ever  been  used  within  the 
context  of  the  current  "history"  file’s  existence.  The  name, 
"EXAMFL",  along  with  its  corresponding  length,  is  placed  within  the 
record.  the  tally  portion  of  the  record  is  set  to  the  current 
value  of  the  tally  (zero,  because  it  is  a  new  record)  plus  a 
specified  tally  increment.  This  information  is  saved  within  the 
instrumentation  package  and  is  also  written  into  the  history  file. 
Consequently,  if  some  error  causes  "EXAMPL"  to  abort  its  execution 
(or  if  it  is  forced  to  abort  by  the  operating  system),  the  tally 
within  the  "EXAMPL"  history  record  is  a  nonzero  positive  number. 
The  nonzero  tally  indicates  that  "EXAMFL"  failed.  The  vaiue  of  the 
tally  represents  the  number  of  times  (only  while  instrumentation  is 
enabled)  "EXAMPL"  must  be  entered  and  exited  successfully,  before 
debug  printout  (trace)  for  "EXAMPL"  will  stop. 
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If  "EXAKPL"  has  no  "abortive  bugs,"  just  prior  to  exiting,  the 
tally  of  its  history  record  (found  in  the  'HISTRY'  common  area  of 
the  instrumentation  package)  will  be  effectively  decremented  by  one 
(or  set  to  zero  when  decrementing  results  in  a  negative  tally). 
Then  the  record  will  be  placed  into  the  appropriate  place  within 
the  "history"  file,  writing  over  the  old  version  of  the  record. 

E.5  Instrumentation  Package  Programs 

The  following  two  sections  describe  the  program  modules  of  the 
CLPARS  instrumentation  package  available  for  programmer  use.  The 
first  section  describes  the  "necessary"  instrumentation  programs. 
An  example  "usage"  is  given  for  each  program. 

E.5.1  Control  tracing  and  "History"  maintenance  programs 

INSINI  -  Instrumentation  package  initialization,  used  to 
determine  whether  or  not  the  instrumentation 
package  is  to  be  enabled  or  disabled  for  the 
current  execution  of  the  program  calling  INSINI. 

CALL  INSINI  (Name) 

where  "Name"  is  a  Hollerith  string  containing 
the  name  of  the  program  calling  INSINI.  (Name 
should  not  exceed  9  characters. 
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Example:  CALL  INSINI  ( '  CCKL’CT  » ) 

INSFGM  -  Instrumentation  package  program  entrance  monitor 
used  to  indicate  that  the  currently  executing 
program  has  just  been  called  (i.e.,  a  call  to 
this  program  should  be  the  FIRST  executable 
statement  in  a  subprogram) . 

CALL  I NS PGM  (Name,  FgmTyp) 

where  "Name"  is  a  Hollerith  string  containing 
the  name  of  the  program  calling  INS  PGM  (name 
should  not  exceed  9  characters) .  "PgmTyp"  is 
an  integer  specifying  whether  a  program  is  of 
type  "MAIN"  (=0)  or  of  type  "SUEPRCGRAM"  (=1). 

(EIG  NOTE:  'INSINI*  calls  ' INSFGM '  ,  for  the 
user  with  "PgmTyp"  set  to  "MAIN".  Therefore, 
the  user  should  not  call  ' INSPGM'  in  the 
"main"  program  where  'INSINI'  is  used.) 

Example:  CALL  INSFGM  (’GNXTND',1) 

CALL  INSFGM  ( ' EQUALA • , SUEPGM ) 
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II.SF.LT  -  Instrumentation  package  exit  rr.cr.itor,  used  tc 
indicate  chat  the  currently  executing  program 
is  about  tc  exit  (i.e.,  a  cell  tc  this  program 
should  be  the  LAST  executed  statement  in  the 
calling  program.)  . 

Example:  CALL  IIISRET 

ILSSET  -  Sets  instrumentation  package  to  a  desired  state, 
either  "on"  or  "off".  The  previous  state  of  the 
instrumentation  package  is  returned  to  the 
calling  program. 

CLSTAT  =  INSSET  (liwStat  .Thresh) 

where  "NwStat"  is  the  new  state  of  the 
instrumentation  package  (true  =  Cfi,  false  r  OFF); 
"Thresh"  is  an  integer  value  representing  the 
new  debug  printout  threshold.  Upon  return, 

II1SSET  will  return  the  old  state  of  the 
instrumentation  package  as  its  function  value 
and  set  "Thresh"  to  the  previous  threshold  value 
of  the  package. 

Example:  THRESH  =  3 

CLSTAT  =  INSSET (  .true  .  ,  THRESH) 
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.2  Variable  trace  programs 

IhSCHR  -  Prints  cut  the  value  of  a  character 
string  variable  (i.e.,  prints  out 
characters  stored  in  an  integer  array, 
one  character  per  integer)  . 

CALL  INSCHR  (Name,  Value,  Length) 

where  "Name'*  is  a  Hollerith  string 
containing  the  name  of  the  variable  to 
be  printed  (or  some  pertinent  descrip¬ 
tion);  "Value”  is  the  address  of  the 
variable  to  be  printed;  "Length"  is  the 
number  of  characters  to  be  printed, 
when  zero,  the  last  character  in  the 
string  must  be  followed  by  a  zero,  the 
end-of-string  symbol. 

Example:  CALL  INSCHR  ('CHAR',  CHAR,  10) 

CALL  INSCHR  (’Tree  Name’,  TNAM ,  C) 


215 


nstrun.entsticn  debug)  package  —  E 

II.SLLL  -  Frir.ts  cut  the  vclue  cf  a  double  precision 
floating  point  variable. 

CALL  ItiSLLL  (Lame,  Value) 

where  "Lame"  is  s  Hollerith  string  con¬ 
taining  the  name  of  the  variable  to  be 
printed;  "Value"  is  the  address  of  the 
double  precision  variable  to  be  printed. 

Example:  CALL  ItiSCEL  (’ CCRREL  ’  ,  CCRREL) 

INSFLT  -  Prints  out  the  value  cf  a  single  precision 
floating  point  variable. 

CALL  INSFLT  (Lame,  Value) 

where  "Lame"  is  a  Hollerith  string  con¬ 
taining  the  name  of  the  variable  to  be 
printed;  "Value"  is  the  address  of  the 
single  precision  variable  to  be  printed. 

Example:  CALL  INSFLT  ('FAST',  FAST) 
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ILSIKT  -  Prints  cut  the  value  cf  the  integer  variable. 

CALL  IKSINT  (I.'ame ,  Value) 

where  "Name"  is  a  Hollerith  string  con¬ 
taining  the  name  of  the  variable  to  be 
printed;  "Value"  is  the  address  cf  the 
integer  variable  to  be  printed. 

Example:  CALL  INSIHT  ( ' LENGTH  OF  NAME*,  I) 

INSLCG  -  Prints  cut  the  value  of  a  logical  variable. 

CALL  IK SLOG  (Name,  Value) 

where  "Name"  is  a  Hollerith  string  con¬ 
taining  the  name  cf  the  variable  to  be 
printed;  "Value"  is  the  address  of  the 
logical  variable  to  be  printed. 

Example:  CALL  INSLOG  ('FIRST  TIME  FLAG',  FRSTIK ) 
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E.c  dome  Notes  About  Instrumentation  Fackage  I'se  on  RSX-1  1 M 

The  instrumentation  package  has  its  own  cedicated  logical  unit 
(for  output)  so  that  a  programmer  has  the  ability  tc  cirect  the 
debug  output  tc  various  computer  peripheral  devices  (cisk,  line 
printer,  terminal,  etc.).  Normally,  ur.cer  RSX-1  It'!,  the 
instrumentation  package  puts  its  output  onto  the  "system"  disk  in 
the  file  ’ INSTRU. EAT  ’  .  This  can  be  modified  during  the  task  build 
(linking)  stage  (see  ASC  parameter  in  F.SX-1  1M  task  build  manual)  or 
immediately  prior  tc  program  execution  (see  REA  command  directive 
in  the  RSX-1 IN  operator's  procedures  manual).  Note  also  that  if 
the  device  'XAC:'  is  defined,  ' INSTRL . EAT '  will  be  placed  on  that 
device  instead  of  the  "system"  (SYC:)  device. 

The  logical  unit  used  in  CLPARS  will  be  logical  unit  number 
two.  This  logical  unit  assignment  will  not  be  guaranteed,  however, 
unless  prog  rammers  call  the  instrumentation  initialization  routine 
(IkSIM)  before  any  other  files  are  opened.  In  general,  it  would 
be  a  good  practice  to  make  a  call  to  '  IKSIKI'  the  first  executable 
statement  in  an  CLFARS  "main"  program.  This  convention  is 
necessary  because  logical  unit  assignment  to  files  opened  within  a 
program  are  dene  on  a  first-come,  first-served  basis  (Logical  unit 
two  happens  to  be  the  first  unit  in  the  list  of  available  logical 
units).  If  the  convention  is  net  followed,  a  programmer  who 
desired  to  redirect  the  debug  output  would  have  tc  figure  out,  for 
each  program  written,  to  which  logical  unit  the  instrumentation 
package  was  attached. 
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CLPARS  RSX11M  I/C  Notes 


F.l  Access  tc  CLPARS  User's  Files 

All  access  to  any  of  the  CLFARS  User's  Files  ..ill  be  obtained 
through  the  level  II/level  I  manipulation  and  access  routines  (see 
Figure  F-1 ) . 

F . 1 . 1  (Fixed  Files) 

The  level  II  manipulation  routines,  CPENFX  and  CREAFX,  "know" 
the  size  of  the  headers  and  logical  entries  of  all  the  fixed  files. 
To  open  the  files,  these  two  routines  call  the  level  I  routines, 
OCFEN  and  CCREAT,  respectively.  OCFEN  and  CCREAT  retrieve/ insert 
the  system  pointer  (i.e.,  the  system  file  name)  to  the  fixed  file 
from/to  the  File  Code  Table  file,  via  the  fixed  file's  file  code. 
(The  file  codes  for  the  fixed  files  are  predefined  to  be  the  values 
1  through  10).  COPEN  and  CCREAT  then  open  the  file  and  fill  in  the 
appropriate  information  in  the  File  Access  and  Control  Table 
(FACT).  Cnee  the  FACT  is  filled  in  by  the  manipulation  routines, 
the  CLPARS  fixed  files  can  be  accessed  by  the  level  II  access 
routines,  through  the  level  I  access  routines,  FGET  and  FPUT. 
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F 


F.1.2  (Data  and  Logic  Files) 

The  level  II  manipulation  routines  CPENTR  and  CREATR  "knew" 
the  size  of  the  headers  of  a  user's  data  and  logic  files.  They 
must,  however,  calculate  the  size  of  a  logical  entry  in  these 
files.  The  dimensionality  of  the  data  set,  used  to  create  the  data 
or  logic  tree,  is  all  that  is  necessary  for  this  calculation.  This 
information  is  stored  in  the  Tree  List  and  Logic  List  files,  along 
with  a  tree's  file  codes,  which  are  used  to  retrieve  (from  the  File 
Code  Table)  the  system  names  of  the  files  that  are  used  to  simulate 
the  CLPARS  tree.  The  files  are  opened  by  either  CCPEN  or  CCREAT. 
From  this  point,  operations  continue  as  mentioned  under  "Fixed 
Files." 

F.2  OLPARS  Block  I/O  (File  Access  and  Control  Table)  Notes 

Currently,  the  file  access  and  control  table  has  the 
capability  to  have  fifteen  block  I/O  files  open  at  one  time. 
However,  the  entire  FACT  is  not  allocated  at  compile  time.  The 
reason  for  this  was  to  save  task  space.  The  FACT  was  broken  into 
two  FORTRAN  common  areas.  Everything  but  the  Physical  Record 
Buffer  (PRBUFF)  area  was  put  in  the  common  area  labeled  FACT.  The 
Physical  Record  Euffer  was  placed  in  its  own  common  area,  called 
BLKEUF.  The  portion  of  the  file  access  and  control  table  that  is 
in  the  FACT  common  area  has  enough  space  for  the  fifteen  open 
files,  as  mentioned  above.  The  BLKBUF  common  only  has  enough  space 
allocated  for  one  block  (256  word)  buffer.  (These  allocations  are 
compile  time  allocations)  . 
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The  EL LEIF  area  car.  be  extended  at  task  build  (link)  time  by 
using  the  task  builcer  EXTEC?  cirective.  This  gives  a  programmer 
the  ability  to  specify,  exactly,  tr.e  r.umter  of  block  I/C  buffers 
(maximum  =  15)  to  create,  according  tc  the  number  cf  files  (to  be 
accessed  using  block  I/C)  tr.at  are  opened  at  any  cr.e  time.  (See 
CLFARS  command  task  building  notes  for  F.SX-1  Itf,  in  section  F.5). 

The  FREUFF  is  separated  from  the  FACT  solely  for  the  purpose 
of  adjusting  its  size  at  task  build  time  (because  this  was  the  only 
way  it  could  be  dene) . 

F.3  CLPARS  Record  I/O  Notes 

Terminal  and  sequential  file  access  is  done  through  RSX-11's 
record  I/C  facility.  RSX  record  I/O  has  a  buffei  region  that 
corresponds  to  the  CLPARS  block  I/O  buffer,  BLKBUF.  The  buffer  is 
called  $$FSR1.  This  region's  size  is  also  controlled  at  task  build 
time,  like  the  ELKBUF  region.  In  this  case,  however,  the  region's 
size  is  controlled  by  the  ACTFIL  task  build  parameter,  instead  of 
the  EXTSCT  parameter. 
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F.^  CLFARS  File  I/C  Communication  Paths 

Figure  F-1  shews  the  relationship  of  communication  between 
CLPARS  programs,  files,  and  data  areas.  Following  is  an 
explar.  a  tier,  of  the  x'igure. 

F.i.1  (Logical  Unit  Allocation) 

There  is  a  global  common  area  within  CLPARS  which  contains 
controlling  information  about  the  allocation  of  logical  unit 
numbers  for  both  record  and  block  I/O.  The  area  is  described  as 
the  currently  available  logical  unit  numbers  table  (CALUN).  The 
table  contains  information  about  15  logical  unit  numbers.  Logical 
unit  numbers  are  dispensed,  upon  request  from  the  "get  logical  unit 
number  program"  (GTLUh),  on  a  first  come,  first  serve  basis.  GTLUK 
searches  the  table  from  beginning  to  end  for  a  free  unit.  When  one 
is  found,  GTL UK  marks  the  unit  as  being  used  and  returns  the  unit 
number  to  its  calling  program. 

Logical  units  become  "free"  or  available  when  the  "release 
logical  unit  number  program  (RELUN)  marks  a  unit  for  reuse. 

The  purpose  behind  this  type  of  logical  unit  allocation  was  to 
free  the  programmer  from  "worrying"  about  which  logical  units  could 
be  used  when  opening  a  file. 
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F.i.2  ( Block  I/C) 

A  command  program  that  accesses  an  CLFAF.S  user's  fixed  data  or 
logic  files  must  first  call  the  appropriate  level  II  "open"  routine 
(i.e.,  CFEIJTR  or  CREATE  for  tree  files,  CPEHFX  or  CREAFX  for  fixed 
files).  If  a  tree  file  is  being  opened,  information  about  the  file 
must  be  retrieved  from  (or  placed  into  when  creating)  the  Tree  (TL) 
or  Logic  List  (LL)  file.  From  this  point,  all  remaining  actions 
occur  for  both  tree  and  fixed  files.  The  level  II  "open"  routines 
call  the  level  I  "open"  routines.  They,  in  turn,  open  the  File 
Cede  Table  and  retrieve  the  "system"  file  name(s)  of  the  file(s)  to 
be  opened.  The  level  I  open  routines  call  the  level  zero*  block 
I/C  open  routines  (FGFEN,  FCREAT)  to  actually  open  the  "system" 
files.  These  routines  request  a  logical  unit  number  from  the 
available  pool  of  numbers  (as  mentioned  above)  and  open  the  system 
file,  which  causes  system  file  information  to  be  placed  into  the 
device  table  ($$DEVT).** 


*  Level  0  programs  mentioned  here  are  RSX-1 IK  assembly  programs 
that  communicate  with  the  operating  system  directly  for 
opening,  closing,  reading,  writing,  etc.  of  a  file. 

**  The  logical  unit  number  is  used  as  an  index  pointer  into  the 
device  table. 
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The  logical  unit  number  is  returned  tack  to  the  level  I  "cper." 
routines.  The  "open”  routines  locate  a  free  file  descriptor  within 
the  File  Access  and  Control  Table  (FACT),  through  che  "get  file 
descriptor  program"  (GETFID).  Cr.ce  the  file  descriptor  is 
obtained,  the  logical  unit  number,  along  with  other  appropriate 
information,  is  placed  in  the  FACT.  The  level  I  "open"  routines 
return  to  the  level  II  "open"  routines  the  value  of  the  file 
descriptor,  which  is  subsequently  given  to  the  upper  level  and 
support/command  programs. 

Cnee  the  files  are  opened  ,  they  can  be  accessed  by  the  command 
programs  through  the  level  II,  level  I,  level  C  path  of  programs. 
The  level  I  access  routines  (FGET,  FPUT)  use  the  previously  stored 
file  access  information  in  the  FACT  to  direct  the  level  zero 
routines.  The  level  zero  routines  perform  the  actual  block  I/C 
access  cf  the  RSX-1 1M  system  files.  The  routines  pi ace/retrieve 
those  blocks  into/from  the  Fhysical  Record  Euffer  area  (PREUFF)  in 
the  FACT.* 

To  close  the  CLPARS  block  I/O  accessed  file,  one  of  the 
appropriate  level  II  "close"  routines  (CLOSTR,  CLOSFX)  is  called. 
The  level  II  "close"  routines  pass  the  file  descriptor  to  the  level 
I  close  routine  (OCLOSE).  It  obtains  the  logical  unit  of  the  file 
to  be  closed  from  the  FACT  and  calls  the  level  0  close  routine. 
The  "system"  file  is  closed  (this  clobbers  information  in  $$DEVT) 


The  PRBUFF  is  not  actually  contained  "in"  the  FACT,  but  is 
considered  part  of  it. 
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and  the  logical  unit  is  marked  "as  available"  in  the  logical  unit 
pool . 


F.U.3  (Record  I/O 

A  command  program  that  accesses  the  user’s  terminal  simply 
uses  the  terminal  I/C  package  (TRMGET/TRMPUT )  .  Internally, 
however,  the  terminal  access  programs  can  "sense"  when  their 
special  logical  unit**  has  been  opened  or  not.  When  the  unit  is 
closed,  TRNCET  or  TRMPUT  makes  a  call  to  the  terminal  open  routine 
(TP.KCFN,  found  in  the  level  0  file  manipulation  routines).  The 
"system"  then  places  information  about  the  file  (terminal)  into  the 
device  table  ($$DEVT).  The  terminal  routines  now  have  the  ability 
to  access  the  terminal. 

To  access  an  RSX-1 1M  sequential  (variable  length  recora)  file, 
the  command  or  support  program  must  first  open  the  file  with  the 
support  file  "open"  routine  (OPENS).  The  support  routine  calls  a 
record  I/C  level  zero  "open"  routine  (VOPEN,  VCREAT)  to  perform  the 
actual  "system"  open. 

As  in  block  I/O  "opens,"  the  level  zero  "opens"  requests  a 
logical  unit  number  to  use  and  performs  the  "system  open,"  which 
fills  in  the  device  table.  This  unit  number  is  transferred 
directly  back  to  the  program  that  requested  the  file  to  be 
"opened".  The  sequential  file  access  programs  (FILGET,  FILPUT)  can 


**  Logical  unit  1  has  been  reserved  for  terminal  I/C  and  is  not 
found  in  the  currently  available  logical  unit  table. 
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new  access  the  opened  file.  (Information  is  buffered  in  the  CCFSR1 
region  for  both  the  terminal  access  and  sequential  file  access 
programs ) . 

To  close  a  sequential  file  (thus,  flushing  its  buffer),  the 
support  file  manipulation  "close'*  routine  must  be  called.  This 
routine  calls  the  level  zero  close  routine,  which  closes  the  file 
and  releases  the  logical  unit  number  in  use. 


F.5  CLPARS  Command  Task  Building  Notes  for  RSX-1 1M 


Disregarding  the  possibility  of  programs  being  "overlaid,"  the 
following  RSX  parameters  will  be  used  when  task  building  (linking) 
an  CLPARS  command  program.  They  are: 

ACTFIL,  EXTSCT,  UNITS,  GBLPAT,  and  ASG 


where , 

ACTFIL  -  specifies  the  number  of  record  I/O  files  to 
be  open  at  any  one  time.  This  parameter 
regulates  the  size  of  the  record  I/O  buffer 
region  ($$FSR1). 

EXTSCT  -  is  used  to  control  the  size  of  the  block  I/O 
buffer  region  (ELKBUF). 

UNITS  -  specifies  the  total  number  of  files  open  at 
any  one  time  (that's  both  record  and  block 
I/O  files).  This  parameter  controls  the 
size  of  the  logical  unit  device  table  region 
( $$DEVT ) . 

is  used  to  specify  the  number  of  block 


GBLPAT 


CLFAES  I/C  notes  (on  REX-1 1M  operating  system)  --  F 

buffers  allocated.  The  use  cf  this 
parameter  will  help  protect  the  programmer 
when  developing  and  debugging  a  new  program. 
It  will  prevent  him  from  clobbering 
(writing  over)  data  areas  outside  the  block 
buffer  region  (ELKEUF). 

ASG  -  is  used  to  assign  logical  units  to 

particular  devices  at  task  build  time. 
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The  following  is  an  example  of  a  task  build  command  file  for 
building  a  non-cverlaid  CLPARS  command.  For  more  detail,  refer  to 
the  RSX-1 IK  task  builder  manual. 


PRCCRAK/CF/FPsPRCGRAH, [313, 323CLPARSLIB/LE 

9 

; PROGRAM  -  name  of  the  CLFARS  command  being  built 


/CF  -  makes  task  checkpointable,  so  it  can  be  swapped  out  of 
memory  in  a  multi-user  environment. 


/FP  -  tells  task  builder  that  the  floating  point  processor 
is  used  by  the  task 


[312, 32]0LPARSLIB/LB  -  the  CLPARS  subprogram  library, 
which  happens  to  be  in  directory  [313,22] 


/ 

;There  is  one  record  I/O  file  open  in  FRCGRAM. 

ACTFIL  =  1 

9 

;There  is  one  block  I/O  file  open  in  PROGRAM. 

EXTSCT  =  BLKBUF: 100G 
GBLPAT  =  PROGRAM :BUFCNT: 1 

9 

;Note:  Eoth  numbers  in  the  above  parameters  are  octal.  ELKBUF's 

;  size  is  in  bytes.  It  should  be  extended  (for  more  block 

;  I/O  files  to  be  opened)  in  increments  of  1000  (8)  or 

;  512  (1C).  If  neither  parameter  is  used  above,  it  should 

;  be  known  that  there  is  one  block  buffer  allocated  at 

;  compile  time  (i.e.,  BLKBUF  has  512  (10)  bytes  allocated 

;  and  EUFCNT  is  set  to  1). 


;  There  are  a  total  of  two  files  opened  at  any  one  time  in  FRCGRAM. 
;  Currently  the  maximum  number  allowed  is  15. 

UNITS  =  2 

I 

;  Logical  unit  1  should  ALWAYS  be  assigned  to  the  terminal  device. 

;  The  remaining  logical  units  are  assigned  to  the  "system"  device. 
ASG  =  TI: 1,  SY : 2 
// 
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APPENDIX  G 

OLPARS  Programmer  Aides 


The  following  pages  contain  information  on  how  to  use  the 
CLPARS  programmer  aides.  The  current  programmer's  aides  are  CE1I, 
INSHSP,  MAKCPT,  CDTEMP,  and  OLTCMP.  GEN  is  used  to  generate  a  new 
CLPARS  user  directory  (see  APPENDIX  C)  ,  expand  an  old 
user-directory,  or  give  a  list  of  the  number  of  trees  a  user  is 
allowed.  INSHSP  can  be  used  to  activate  or  deactivate  debug 
print-cut  of  specific  programs  when  program  instrumentation  is 
present  in  the  task  and  turned  on.  KAKOPT  is  used  to  create  the 
OLPARS  option  file  (see  Appendix  E)  .  CDTEMP  and  CLTDKP  can  be  used 
to  dump  the  structural  content  of  an  CLPARS  data  or  logic  tree, 
respectively . 

The  format  of  the  aid  descriptions  is  identical  with  the 
OLPARS  User's  Manual  format. 


li 
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CLPARS  Programmer  Aides  -- 

CE 


CCKKAI.D  KANE :  GEN 


CATEGCRY:  Programmer's  Aide  (system  dependent) 


FUNCTIONAL  DESCRIPTION: 

The  GEN  utility  creates  all  the  necessary  CLPARS  'fixed' 
files  that  are  required  by  an  CLPARS  user.  File  headers 
are  appropriately  initialized.  GEN  also  sets  up  the  File 
Code  Table,  which  specifies  the  total  number  of  trees 
(cata/logic)  that  an  CLPARS  user  is  allowed  to  have  in 
his  directory.  The  user  has  the  additional  options  of 
expanding  his  tree  capacity  (allow  for  more  trees)  and 
of  printing  out  his  tree  capacity  (list  out  the  number 
of  trees  allowed,  the  number  of  trees  currently  existing, 
and  the  remaining  number  of  trees  allowed). 

USER  INTERACTION: 

There  are  three  possible  ways  to  run  gen: 

1)  GEN<cr> 

2)  GEN  'switch'  <cr> 

3)  RUN  GEM<cr> 

1  and  2  above  assume  that  the  GEN  task  has 
been  installed.  (INS  GEN/TASK= . . . GEN  ) 


GEN  takes  the  following  switches: 

/NW:n  create  a  new  user  with  a  tree  capacity  of  n 
/EX:n  expand  an  old  user's  tree  capacity  by  r. 

/LI  print  out  a  user's  tree  capacity 


CLEARS  Programmer  Aides 
GEt;  (continued) 


G 


I 


L 


EXAMFLE(S): 

Three  examples  of  GE iJ  sessions  will  be  given, 
one  for  each  method  of  running  CEN. 

1)  Session  when  user  types  CEN'<cr> 


/GEN<cr>/ 

G E N > /  /LI<cr>/ 

USER'S  TREE  CAPACITY  =  1C 

THE  NUKEER  OF  TREES  EXISTING  IN  THE  USER'S  DIRECTORY  =  C 

THE  REMAINING  NUMBER  CF  TREES  THAT  THE  USER  IS  ALLOWED 
=  10 

GEN>/<cr>/ 


2)  Session  when 

/GEN  /EX: 20<cr>/ 
> 


user  types  GEN  'switch'  <cr> 


(the  outer-most  slashes  mark 
response) 


user 


3)  Session  when  user  types  RUN  GEIJ<cr> 


/RUN  GEN<cr>/ 

TO  EXPAND  A  USER'S  TREE  CAPACITY,  TYPE  /EX:N 
WHERE  N  IS  THE  NUMBER  OF  TREES  BY  WHICH  TO 
EXPAND  A  USER'S  TREE  CAPACITY 

TO  CREATE  A  NEW  USER,  TYPE  /NW:N 
WHERE  N  IS  THE  NEW  USER'S  TREE  CAPACITY 

TO  PRINT  CUT  A  USER'S  TREE  CAPACITY,  TYPE  /LI 

//NW:5G<cr>/  (the  outer-most  slashes  mark  user  response) 

> 
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CLPARS  Programmer  Aides  --  G 
GEN  (continued) 

(NOTES :  ****»*****»»»**«*****•*•*•«•***«•*»** 

If  the  user  .ypes  tne  switches  to  create  or 
expand  an  CLPARS  directory  (/LX:n  or  /NW:n), 
and  GEN  completes  successfully ,  no  messages 
are  printed  at  the  terminal. 

Running  GEN  by  typing  GEN<cr>  allows  the  user 
to  run  as  many  GEN  options  as  he  wishes.  After 
each  option  has  been  executed,  the  prompt  'GEN>' 
is  put  out  at  the  user’s  terminal.  He  can  then 
type  in  another  option  (switch),  or  type  a 
carriage  return  or  a  control-2  to  exit.  Running 
GEN  using  either  of  the  other  two  methods  (RUN 
GEN<cr>,  or  GEN  'switch'  <cr>)  only  allows  for 
one  option  to  be  executed.  After  execution  of 
the  option,  GEN  halts  and  the  KCR  prompt  (>) 
is  put  up  at  the  user's  terminal. 

In  the  examples  above,  the  expression  /  /LI/ 
means  that  the  user  typed  "  /LI". 

Typing  a  space  before  a  switch  or  before  a 
carriage  return  is  optional. 

»***»**»*««*«««*««««***»»•«**«*«•***«**« *#******#***) 


GLPARS  Programmer  Aiaes  --  G 
INSHSF 

COMMAND  NAME :  INSHSF 


CATEGORY:  Programmer's  Aide 


FUNCTIONAL  DESCRIPTION: 

INSHSF  (Instrumentation  History  file  Patch)  can  be  usea 
by  an  CLPARS  programmer  to  activate  or  deactivate 
instrumentation  for  a  selected  set  of  CLPARS  subprograms. 
This  can  help  keep  the  amount  of  printed  information  in 
the  instrumentation  output  to  a  minimum. 

USER  INTERACTION: 

User  is  asked  : 

1.  for  the  name  of  the  file  containing  names  of 
programs  to  activate  or  deactivate  in 
instrumentation. 

2.  to  'activate'  or  'deactivate'  given  programs 


EXAMPLE (S ) : 

A  file  (OLPPGMS.TXT)  has  been  created  containing  the 
names  TLSRCH,  GARBND,  ECUALA,  and  OPEN’TR  on  separate 
lines  (upper  case  letters  are  important).  The  program 
CCEFAULT  has  been  executed  to  set  the  instrumentation 
'ON'  and  set  the  instrumentation  threshold  to  five 
(this  will  silence  the  other  succesfully  executed 
programs)  . 

TYPE  IN  FILENAME  CONTAINING  NAMES  OF 
PROGRAMS  TO  ACTIVATE/DEACTIVATE  -  /OLPPGMS.TXT/ 
ACTIVATE  OR  DEACTIVATE  (A/D)?  /A/ 

( PROM  FT  NOTES:  ************************************* 

If  the  next  GLPARS  command  executed  enters  any  of  the 
programs  'activated',  then  instrumentation  will 
appear  for  those  programs.  Note:  instrumentation 
may  also  appear  for  any  programs  that  exceed  the 
current  instrumentation  threshold  requirements  other 
than  those  specified  thru  'activation'. 

The  program  activation  will  last  at  least  five  times 
the  number  of  times  the  program  name  appears  in  the 
activation  file.  So,  if  a  program's  name  appears 
once  in  the  activation  file,  and  it  is  successfully 
executed  five  times,  then  instrumentation  will  cease 
for  that  program. 

»**************»•******«*»*«**»*»*»*****•»******»***) 
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KAKGPT 


COMMAND  NAME:  KAKCFT 


CATEGORY:  Programmer's  Aide  (system  dependent) 


FUNCTIONAL  LESCRIFTICN : 

MAKCPT  creates  the  GLPARS  option  file  (CPTICN.CLP) 
within  the  CLPARS  directory.  MAKCPT  uses  the  option 
text  file  (CPTICN.TXT)  as  an  input  file.  This  program 
should  be  used  only  by  CLPARS  programmers/maintainers 
to  create  the  proper  option  file.  See  Appendix  L  of 
this  manual  for  a  description  of  CFTICN.CLP  and 
OPTICN.TXT  and  for  information  on  future  Cption 
File  Maintenance. 

USER  INTERACTION:  NONE 

(NOTES:  ******************************************** 

If  for  some  reason  MAKOPT  cannot  create  the  option 
file,  an  appropriate  error  message  will  be  printed 
at  the  user's  terminal,  and  the  program  will  exit. 

If  the  program  completes  successf ul ly ,  the  number 
of  program  names  processed  is  printed  at  the  user's 
terminal . 

•a****#*#**###**************#*#*************#****#**) 


OLPARS  Programmer  Aides  --  G 
GDTLMP 


COMMAND  NAME :  GDTLMP 

CATEGORY:  Frogra  cr's  Aide 

FUNCTIONAL  DESCRIPTICN: 

The  GDTLMP  (OLPARS  Data  Tree  Dump)  utility  is  used  to 
check  the  structural  integrity  of  an  CLPARS  data  tree. 

USER  INTERACTION : 

User  types  'RUN  <pathname>ODTr)M  p '  to  initiate  the 
program.  <pathname>  is  whatever  is  needed  to  locate 
the  program. 

Once  the  program  is  running,  the  user  is  asked  for  the 
name  of  the  CLPARS  data  tree  to  be  dumped. 

NOTE:  To  use  this  program  properly,  you  must  be 

'in'  the  CLPARS  user’s  directory  where  the 
data  tree  to  be  dumped  is  located . 

EXAMPLE(S) : 

The  tree  'nasal'  is  going  to  be  dumped. 

1)  RUN  DB: [313,^0]CDTDMP 

2)  the  program  prompts  the  user  with: 

OLPARS  DATA  TREE  NAME  -  /nasal/ 
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ODTLKF  (continued) 


3)  results  in: 

STRUCTURAL  DESCRIPTION  OF  OLPARS  TREE  nasal 

3  NODES  IN  TREE 

12  IS  VECTOR  DIMENSIONALITY 

C  NODES  IN  FREE  LIST 

1  IS  SENIOR  NODE  SLOT  IN  ENTRY  TAELE 
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CLPARS  Programmer  Aides  --  G 
ODTLKF  (continued) 


(PROMPT  NOTES :  ************************************* 

If  you  wish  to  exit  from  CDTBMP  at  the  tree  name 

prompt,  enter  an  empty  line. 

Following  is  an  expansion  of  the  abbreviated  headings 

in  the  counts  and  pointers  table  seen  in  the  previous 

example . 

VEC  -  the  number  of  vectors  that  ’lie'  at  the  given 
node . 

VCP  -  the  position  of  the  vectors  in  the  Tree 
Vector  file  for  the  given  lowest  node. 

LNC  -  lowest  node  count,  the  number  of  lowest  nodes 
beneath  the  given  node. 

KID  -  the  number  of  children  (kids)  for  the  given 
node . 

NL  -  node  level  of  the  given  node. 

P  -  parent  of  the  given  node. 

S  -  sibling  of  the  given  node. 

FC  -  first  child  of  the  given  node. 

FLN  -  first  lowest  node  of  the  given  node 

LNL  -  lowest  node  link,  node  following  the  given 
node  in  the  lowest  node  chain. 

LNB  -  lowest  node  back  link,  node  preceding  the 
given  node  in  the  lowest  node  chain. 

X******«****»»«**«X****«XX«**X«««******«***KX«X**«*X) 
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CLTEMP 


COMMAND  MAKE:  GLTDKP 


CATEGORY:  Programmer's  Aide 


FUNCTIONAL  DESCRIPTION: 

The  CLTEMP  (GLPARS  Logic  Tree  Lump)  utility  is  used  to 
check  the  structural  integrity  of  an  GLPARS  logic  tree. 

USER  INTERACTION: 

User  types  ’RUN  <pathname>GLTLM P '  to  initiate  the 
program.  <pathname>  is  whatever  is  needed  to  locate 
the  program. 

Once  the  program  is  running  ,  the  user  is  asked  for  the 
name  of  the  CLPARS  logic  tree  to  be  dumped. 

NOTE:  To  use  this  program  properly,  you  must  be 

•in'  the  CLPARS  user's  directory  where  the 
logic  tree  to  be  dumped  is  located. 

EXAMPLE (S ) : 

The  tree  'EXAMPLE'  is  going  to  be  dumped. 

1)  RUN  CB: [313,40]0LTDMP 

2)  the  program  prompts  the  user  with: 

OLPARS  LOGIC  TREE  NAME  -  /EXAMPLE/ 


CLPAKS  Programmer  Aides 
CLTDMF  (continued) 


G 


3)  results  in: 


STRUCTURAL  DESCRIPTION  OF  CLPARS  LOGIC  TREE  EXAMPLE 

DESIGN  DATA  SET  -  EXAMPLE 
DIMENSIONALITY  -  4 
CLASS  COUNT  -  4 
NODES 

NEXT  AVAILABLE (8 )  AT  END  OF  FILE(9)  IN  USE(6) 
(NODES  IN  FREE  LIST  8  7  ) 

CURRENT  LOGIC  NODE  -  4 
REASSOCIATED  NAMES  -  NO 
LV  ENTRY  SIZE  -  12 

INCOMPLETE  NODE  CT.-  4 

DDS  CLASSES  PRESENT  IN  TREE,  WITH  A-PRIORI  PROBABILITY 
ABC  C.254  DEFG  0.254  CAT  0.288  SAND  0.203 
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GLPARS  Programmer  Aides  --  G 
OLTLMP  (continued) 


(PROMPT  NOTES:  ************************************* 

If  you  wish  to  exit  from  OLTLMP  at  the  tree  name 
prompt,  enter  an  empty  line. 

Following  is  an  expansion  of  the  abbreviated  heaaings 
in  the  counts  and  pointers  table  seen  in  the  previous 
ex  ample . 

NL  -  node  level  (with  senior  node  starting  at  zero) 
KID  -  number  of  children  below  a  given  node 
PP  -  parent  of  the  given  node. 

FC  -  first  child  of  the  given  node. 

SB  -  sibling  of  the  given  node. 

LVP  -  decision  logic  vector  pointer  to  LV  file 
RJP  -  reject  logic  pointer  to  LV  file 

GCNM  -  original  data  class  name  (should  have  value  when 
only  one  class  exists  at  the  given  logic  node) 

RCNM  -  reassociated  class  name  (should  have  value  when 
only  one  class  exists  at  the  given  logic  node) 

MLF  -  modified  logic  flag 

NCP  -  number  of  classes  present 

PR  -  class  symbols  of  classes  present  at  given  node 

••••a**##*#*####*##**#####***#*###*##***#####*#**#**) 
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AFPENDIX  H 


CLPARS  Parameter  Limits 


This  appendix  defines  parameter  limits  (minimum  and  maximum 
values)  for  parameters  used  in  CLPARS.  These  parameters  can  be 
utilized  by  including  the  appropriate  declaration  file  in  the 
source  program.  The  parameters  are  first  grouped  according  to 
alphabetical  order.  Their  ’location'  (the  file  in  which  the 
parameter  can  be  found)  is  determined  by  attaching  a  file  <type> 
name  of  '.CCL'  to  the  name  given  in  the  list  (E.G.,  SCREEN. CCL). 
The  second  grouping  lists  the  parameters  according  to  the  file  in 
which  they  reside. 


Parameter  Value  Location  Description 


A 

7 

SCREEN 

index  to  the  x-coordinate  of 
the  lower  left  point  of  the 
display  rectangle 

ACCESS 

0 

DISPLAY 

indicator  that  an  item  is  to  be 
read  from  a  display  file  header 

ALIFLG 

7 

LIHDR 

alias  flag 

ALPHA 

1 

CHARTYPE 

used  when  characters  in  name 
can  only  be  alphabetic 

ALPHNM 

2 

CHARTYPE 

used  when  characters  in  name 
can  be  alpha-numeric 

ANGLE 

0 

DISPLAY 

dummy  angle  parameter  for  btmap 
routines 

GLPARS  Parameter  Limits  --  H 

Alphabetizea 


Parameter  Value  Location  Description 


A NYC HR 

3 

ChARTYPE 

APPEND 

2 

STANDARD 

B 

8 

SCREEN 

BMPSIZ 

2 

BITMAP 

BFET 

12 

TIFILE 

BUFSIZ 

128 

FACT 

C 

9 

SCREEN 

CAPSIZ 

12 

TIFILE 

CLPBMS 

5 

RNKORD 

CLSBMS 

4 

RNKORD 

CLSDBN 

4 

LCGTYPE 

CLUSTR 

1 

DISPLAY 

CM 

1 

FCDS 

CMDLEN 

10 

STANDARD 

CKHNE 

97 

LENGTH 

used  when  any  printable  ASCII 
character  (PASCII),  DIGIT,  or 
LETTER  is  allowed  in  an 
id  entif ier 

open-for-writing-at-the-end-of- 
the-file  indicator 

index  to  the  y-coordinate  of 
the  lower  left  point  of  the 
display  rectangle 

the  size  of  the  classes  present 
bitmap  on  PDP-11  machines  (when 
the  maximum  number  of  classes 
is  equal  to  50) 

the  back  pointer  to  the  entry 
table  slot  number  of  a  node 

physical  record  buffer  size  (in 
real  elements) 

index  to  the  x-coordinate  of 
the  upper  right  point  of  the 
display  rectangle 

the  size  of  the  counts  and 
pointers  region  of  a  TI  node 

class  pair  by  measurement  type 
of  ranking 

class  by  measurement  type  of 
ranking 

closed  decision  boundary  logic 
nodes 

the  display  code  for  a 
two-space  cluster  plot 

communications  file  code  (FCD) 

maximum  character  length  of  a 
command 

the  length  (in  real  elements) 
of  the  communications  file 
header 
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Alphabetized 


H 


Parameter  Value  Location  Description 


CKLENE 

0 

LENGTH 

the  length  (in  real  elements) 
of  a  logical  entry  of  the 
communications  file 

CCNMAT 

DISPLAY 

the  display  code  for  a 

confusion  matrix  display 

D 

10 

SCREEN 

index  to  the  y-cocrdinate  of 
the  upper  right  point  of  the 
display  rectangle 

DATA 

1 

STANDARD 

data  tree  indicator 

DC 

1 

RNKORD 

the  index  in  the  DI  file  array 
for  the  display  code 

DDSDIM 

1 

LIHDR 

design  data  set  dimensionality 

DDSNLN 

2 

LIHDR 

number  of  lowest  nodes  in 

design  data  set 

DELETE 

1 

STANDARD 

cr eat ing-a- temporary -file 
indicator 

DI 

FCCS 

display  information  file  code 
( FCD) 

DIGIT 

2 

CHARTYPE 

means  character  is  a  digit 

DIHNE 

1 

LENGTH 

the  length  (in  real  elements) 
of  the  display  information  file 
head  er 

DILENE 

1 

LENGTH 

the  length  (in  real  elements) 
of  a  logical  entry  of  the  logic 
list  file 

DINITM 

17 

DISPLAY 

the  number  of  DI  file  header 
elements  referenced  by 
subroutines  DIGHDI  and  DIPHDI 

DS 

19 

SCREEN 

index  to  the  distance  between 
succesive  one  space  'macro' 
display  base  lines 

DSPCHR 

8 

RNKORD 

the  index  in  the  DI  file  array 
for  the  ordered  list  of  display 
characters 

CLPARS  Parameter  Limits  --  ,ll 
Alphabetized 


Parameter  Value  Location  Description 


DV 

DVHNE 

DVLENE 

DVNITM 

E 

ENMEAN 

EOF 

ECS 

ERROR 

EXMLIM 

F 

FCP 

FIXED 

FKIDND 


5  FCLS  display  value  file  code  (PCD) 

1  LENGTH  the  length  (in  real  elements) 

of  the  display  value  file 

header 

1  LENGTH  the  length  (in  real  elements) 

of  a  logical  entry  of  the 

display  value  file 

4  DISPLAY  the  number  of  DV  file  header 

elements  referenced  by 

subroutines  DVGHDR  and  DVPHDR 

15  SCREEN  index  to  the  minimum 

x-coordinate  of  a  one  space 
base  line 

17  TIFILE  the  first  element  number  of  the 

means  in  the  TI  file 

-1  STANDARD  end-of-file  code 

0  STANDARD  end-of-str ing  indicator  for 

integers 

-1  STANDARD  the  standard  error  value 

throughout  CLPARS 

150  LIMITS  the  maximum  number  of 

measurements  allowed  in  a 
vector  in  excess  measurement 
mode 

16  SCREEN  index  to  the  minimum 

y-coordinate  of  a  one  space 
base  line 

7  TIFILE  the  code  for  accesssing  the 

first  child  pointer  of  a  node 

5  FTYPE  the  fixed  file  type  indicator 

4  LISTRC  index  to  the  first  child 

pointer  of  the  current  logic 
node 
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Alphabetized 


H 


Parameter 

Value 

Location 

Description 

FLNP 

8 

TIFILE 

the  code  for  accessing  the 

first  lowest  note  pointer 

FNAMSZ 

13 

FACT 

size  (in  words)  of  system  file 
name 

FNMLEN 

3^ 

STANDARD 

the  maximum  length  of  an  RSX-11 
filename 

FREE 

0 

CALUN 

value  to  indicate  that  a  'LUN' 
is  free 

FRELST 

13 

TIFILE 

pointer  to  the  next  "inactive" 
member  in  the  free  list  (one 
past  the  current  member) 

G 

17 

SCREEN 

index  to  the  maximum 

x-coordinate  of  a  one  space 
base  line 

GRPLGG 

2 

LOGTYPE 

group  logic  nodes  (1-space, 

2-space,  boolean) 

HC 

6 

SCREEN 

index  to  the  number  of  display 
units  in  character  height 

HD 

4 

SCREEN 

index  to  the  number  of  display 
units  in  display  height 

HDRLEN 

3 

OPTION 

the  length  of  a  header  record 
in  OPTION. CLP 

HEADER 

0 

STANDARD 

header  indicator  value  to  the 
’FGET'  and  'FPLIT'  routines 

HELP 

-2 

STANDARD 

the  standard  help  value 

response  from  'TRMGET* 

HGT 

0 

DISPLAY 

dummy  height  parameter  for 

btmap  routines 

HS 

10 

FCDS 

history  file  code  (FCD) 

HSHNE 


1 


LENGTH 


history  file  code  (FCD) 

the  length  (in  real  elements) 
of  the  history  file  header 


CLPARS  Parameter  Limits  --  H 

Alphabetized 


Parameter 

Value 

Location 

Description 

HSLENE 

5 

LENGTH 

the  length  (in  real  elements) 
of  a  logical  entry  of  the 

history  file 

HSN 

2 

SCREEN 

index  to  the  number  of  display 
units  in  screen  height 

HSTBSZ 

503 

HISTRY 

historic  file  table  size 

(important:  prime  no.) 

IGNORE 

-1 

DISPLAY 

indicator  that  an  item  is  not 
to  be  read/written  from/to  a 
display  file  header 

INCPLT 

0 

LCGTYPE 

incomplete  logic  nodes 

INC  I 

0 

DISPLAY 

dummy  indicator  parameter  for 
btmap  routines 

INITHR 

5 

V  i-STRY 

initial  threshold  value  for 

debugging  information 

LCH 

13 

SCREEN 

index  to  the  number  of 

characters  per  line 

LETTER 

1 

CHARTYPE 

means  character  is  a  letter 
(either  UPPER/lower  case) 

LEVEL1 

0 

INSTRU 

initial  debugging  printout 

level 

LIFILE 

3 

FTYPE 

the  logic  information  file  type 
indicator 

LIHENE 

272 

LIFILE 

the  LI  header  number  of 

elements 

LILENE 

22 

LIFILE 

the  LI  logical  entry  number  of 
elements 

LL 

3 

FCCS 

logic  list  file  code  (FCD) 

LLHNE 

2 

LENGTH 

the  length  (in  real  elements) 
of  the  logic  list  file  header 

LLLENE 

25 

LENGTH 

the  length  (in  real  elements) 
of  a  logical  entry  of  the  logic 

list  file 
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Alphabetized 


Parameter 

Value 

Location 

Description 

LNEP 

10 

TIFILE 

the  code  for  accessing  the 
lowest  node  back  pointer  of  a 
node  pointer  of  a  node 

LNCRNT 

6 

LIHDR 

current  logic  node 

LNLP 

9 

TIFILE 

the  code  for  accessing  the 

lowest  node  link 

LOGIC 

2 

STANDARD 

logic  tree  indicator 

LOW  EST 

6 

LGGTYPE 

all  lowest  logic  nodes  in  logic 
tree  (both  complete  and 
incomplete)  (lowest  means,  ' nc 
children ' ) 

LSTRSZ 

7 

LISTRC 

logic  tree  structure  size 

LUNPTR 

1 

CALUN 

'LUN*  pointer  portion  of 

’ Luntbl • 

LVFILE 

4 

FTYPE 

the  logic  value  file  type 

indicator 

LVHENE 

3 

LVFILE 

the  LV  header  number  of 

elements 

LVLMIN 

12 

LVFILE 

the  minimum  length  of  a  logical 
entry  in  the  LV  file 

LVLCGK 

6 

LISTRC 

Logic  value  file  pointer  index 
to  decision  logic  for  given 
logic  node 

LVNELM 

8 

LIHDR 

number  of  elements  in  an  LV 
file  entry 

LVRJCT 

7 

LISTRC 

Logic  value  file  pointer  index 
to  reject  strategy  logic  for 
given  logic  node 

MACRO 

5 

DISPLAY 

the  display  code  for  a 

one-space  macro  plot 

MAIN 

0 

INSGLEL 

signifies  to  INSPGM  that  the 
calling  program  was  a  c  'main' 
program 

_ 
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Alphabetized 


Parameter 

Value 

Location 

MAXbDY 

2 

LIMITS 

MAXBIN 

5C 

LIMITS 

MAXBPT 

6 

LIMITS 

MAXbl'F 

1 

FACT 

MAXCLS 

50 

LIMITS 

MAXDIM 

50 

LIMITS 

MAXFIL 

15 

FACT 

MAXHSP 

20 

HISTRY 

MAXLIN 

133 

STANDARD 

MAXLUN 

15 

CALUN 

MAXMTR 

10 

SMFILE 

MAXNAM 

9 

HISTRY 

MAXOFT 

15 

OPTION 

Description 


maximum  number  of  data 
partitions  (boundaries)  allowed 
to  be  made  on  an  GLPARS  data 
set 

the  maximum  number  of  "bins" 
allowed  in  a  one-space  display 

maximum  number  of  points 
allowed  in  a  two  space  boundary 

the  number  of  physical  record 
buffers  is  originally  set  to 
one  but  will  be  extended  at 
task  build  time 

the  maximum  number  of  data 
classes  allowed  within  GLPARS 

the  maximum  vector 

dimensionality  in  GLPARS  (of 
vectors  not  in  excess 

measurement  mode) 

maximum  number  of  files  that 
can  be  open  simultaneously 

maximum  size  that  the  historic 
stack  pointer  can 

attain 

the  maximum  length  of  an  I/C 
character  string 

maximum  number  cf  available 
logical  unit  numbers 

the  maximum  number  of  matrices 
allowed  to  be  stored  in  the  SM 
file 

maximum  number  of  characters 
allowed  in  an  CLPARS 

command  (program)  name 

the  maximum  number  of  options  a 
program  can  have 


GLPAKS  Parameter  Limits 
Alphabetized 


H 


Farameter 

Value 

Location 

Description 

MAXPGh 

106 

OPTION 

the  maximum  number  of  "program 
names"  that  can  appear  in  the 
CPTIGN.TXT  file 

MAXSEG 

10 

DSCRMTHR 

the  total  number  of  segments 
possible  in  two  user  specified 
boundaries 

MAXSEG 

10 

GP2BLK 

the  total  number  of  segments 
possible  in  two  user  specified 
boundaries 

MAXVEC 

32767 

LIMITS 

largest  number  of  vectors 
allowed  in  an  CLPARS  data  tree 
(system  dependent  on  integer 
size,  2**(number  of  bits  in  an 
integer  -  1 )  -1  ) 

MECLPR 

3 

RNKCRL 

measurement  by  class  pair  type 
of  ranking 

MBYCLS 

2 

RNKORE 

measurement  by  class  type  of 
ranking 

MENUMX 

20 

OPTION 

the  maximum  number  of  menus  per 
program  name 

MENVEC 

-1 

DISPLAY 

the  vector  id  in  the  DV  file 
indicating  that  the  vector  is 
the  mean  vector 

MESVEC 

1 

PVFILE 

the  entry  number  of  tP  * 

measurement  vector  in  the  ,v 
file 

MICRO 

6 

DISPLAY 

the  display  code  for  a 

one-space  micro  plot 

MRW 

1 1 

SCREEN 

index  to  the  number  of  rows  in 
the  cluster  plot  grid 

NC 

18 

SCREEN 

index  to  the  maximum  number  of 
classes  that  can  be  displayed 
on  a  one  space  'macro'  display 
at  any  one  time 

CLPARS  Parameter  Limits  --  H 

Alphabetized 


Parameter 

Value 

Location 

Description 

NCI 

12 

SCREEN 

index  to  the  number  of  columns 
in  the  cluster  plot  grid 

N  DIMEN 

3 

RNKORL 

the  index  in  the  LI  file  array 
for  the  dimensionality 

IIDISf 

6 

LIMITS 

the  maximum  number  of  different 
display  types  found  in  CLPAFiS 

NEW 

1 

STANDARD 

new-file- to-be-opened  indicator 

NFIXFL 

10 

STANDARD 

the  number  of  CLPARS  fixed 

files 

NINCLH 

9 

LIHDR 

number  of  incomplete  logic 

nodes 

NL 

4 

TIFILE 

the  code  for  accessing  the  node 
level  of  a  node 

NLNwlE 

2 

TIFILE 

the  code  for  accessing  the 
number  of  lowest  nodes  beneath 
a  node 

NMVLGG 

3 

LOGTYPE 

nearest  mean  vector  logic  nodes 

NNUSED 

5 

LIHDR 

number  of  nodes  actively  used 
in  logic  tree 

NODENL 

2 

LISTRC 

number-of-nodes-at-next-level 
index  (number  of  children  below 
the  current  node) 

NODLEN 

4 

STANDARD 

maximum  length  of  a  node  name 

NODLVL 

1 

LISTRC 

index  to  the  current  logic 

node's  level  in  the  logic  tree 

NOKIDS 

3 

TIFILE 

the  code  for  accessing  the 

number  of  children  at  a  node 

NOSCRN 

19 

SCREEN 

the  number  of  screen 

coordinates  in  the  CM  file 
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Alphabeti zed 


Parameter 

Value 

Location 

Description 

NOTSET 

0 

DISFLAY 

the  display  code  indicating 

that  the  display  is  not  set 

NOVECS 

1 

TIFILE 

the  code  for  accessing  the 

number  of  vectors  at  a  node 

HGZCGM 

0 

DISPLAY 

the  flag  indicating  that 

zooming  is  not  in  effect 

NRSTNB 

5 

LOGTYPE 

nearest  neighbor  logic  nodes 

NUMCLS 

4 

RNKORD 

the  index  in  the  DI  file  array 
for  the  number  of  classes 

NXTAVN 

3 

LIHDR 

next  available  node  entry  in  LI 
file 

NXTEND 

4 

LIHDR 

next  open  node  entry  at  end  of 
file 

OFF 

0 

DISPLAY 

the  display  flag  value  in  a  DI 
file  logical  entry  that  means 
the  class  should  not  be 
displayed  OR  the  screen 
coordinate  flag  in  the  DV  file 
header  that  means  the  screen 
coordinates  have  not  been 
computed 

CFNLEN 

10 

OPTION 

the  length  of  the  option  file 
name  (OPTICN.CLP) 

OLD 

0 

STANDARD 

old-file-to-be-opened  indicator 

ON 

1 

DISPLAY 

the  display  flag  value  in  a  DI 
file  logical  entry  that  means 
the  class  should  be  displayed 
OR  the  screen  coordinate  flag 
in  the  DV  file  header  that 
means  the  screen  coordinates 
have  already  been  computed 

ONESPC 

1 

DISPLAY 

one-space  indicator 

OFTLE 

9 

OPTION 

the  option  file  (OPTION. OLP) 
logical  entry  size 

=  ( ( MAXO  PT  +  1  )/2 )  +1 

OLPARS  Parameter  Limits  —  H 
Alphabetized 


Parameter  Value  Location  Description 


OFTKUH 

2 

RNKQRD 

the  index  in  the  DI  file  array 
for  the  option  number  cf  the 
creating  command 

OTHER 

4 

CHARTYPE 

means  character  is  not  a 
LETTER,  DIGIT,  or  PASCII 
character 

OVRALL 

1 

RNKCRD 

overall  type  of  ranking 

indicator 

PAIRWS 

1 

LOGTYPE 

pairwise  logic  nodes 

PASCII 

3 

CHARTYPE 

means  character  is  a  visible 
(printable)  ASCII  char,  other 
than  a  DIGIT  or  a  LETTER 

PGMLEN 

10 

OPTION 

the  maximum  number  of 
characters  allowed  in  a  program 
name 

PP 

5 

TIFILE 

the  code  for  accesssing  the 
parent  pointer  of  a  node 

PRNTND 

3 

LISTRC 

index  to  the  parent  node  of  the 
current  logic  node 

PV 

6 

FCDS 

projection  vector  file  code 

( FCD) 

PVHNE 

18 

LENGTH 

the  length  (in  real  elements) 
of  the  projection  vector  file 
head  er 

PVLENE 

1 

LENGTH 

the  length  (in  real  elements) 
of  a  logical  entry  of  the 

projection  vector  file 

PVNITM 

6 

DISPLAY 

the  number  of  PV  file  header 
elements  referenced  by 
subroutines  PVGHDR  and  PVPKDR 

QUIT 

-1 

STANDARD 

the  standard  exit  value 

response  from  'TRMGET' 

READ 

0 

STANDARD 

read  indicator  to  'OPEN' 

routines 
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Parameter  Value  Location  Description 


RECTAL 

0 

DISPLAY 

the  indicator  that  rectangular 
scaling  is  to  be  used  for  a 
two-space  display 

RNKOPT 

5 

RNKORD 

the  index  in  the  DI  file  array 
for  the  rank  order  option 

RNKORD 

3 

DISPLAY 

the  display  code  for  a  rank 
order  display 

RHKPRM 

6 

RNKORD 

the  Index  in  the  DI  file  array 
for  the  rank  option  parameters 

SI 

7 

FCDS 

scratchl  file  code  (FCD) 

S1HNE 

1 

LENGTH 

the  length  (in  real  elements) 
of  the  scratchl  file  header 

S1LENE 

1 

LENGTH 

the  length  (in  real  elements) 

of  a  logical  entry  of  the  t 

scratchl  file 

S1NITM 

4 

DISPLAY 

the  number  of  SI  file  header 
elements  referenced  by 
subroutines  S 1GHDR  and  S1PHDR 

SAVE 

0 

STANDARD 

creating-a-permanent-f ile 
indicator 

SBTMAP 

21 

BITMAP 

the  element  number  in  an  LI 
file  entry  at  which  the  classes 
present  bitmap  starts 

SC2WUM 

13 

SCREEN 

number  of  elements  of  screen 
coordinate  infor-  mation  used 
for  two-space  displays 

SCATTR 

2 

DISPLAY 

the  display  code  for  a 

two-space  scatter  plot 

SIBLND 

5 

LISTRC 

index  to  the  sibling  node  of  , 

the  current  logic  node 

I 

SM 

9 

FCDS 

saved  matrix  file  code  (FCD) 

i 

i, 

. 
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Alphabetized 


Parameter 

Value 

Location 

Description 

SMHNE 

114 

LENGTH 

the  length  (in  real  elements) 
of  the  saved  transformation 
matrix  file  header 

SKLEME 

51 

LENGTH 

the  length  (in  real  elements) 
of  a  logical  entry  of  the  saved 
transformation  matrix  file 

SF 

6 

TIFILE 

the  code  for  accessing  the 

sibling  pointer  of  a  node 

SQUARE 

1 

DISPLAY 

the  indicator  that  square 
scaling  is  to  be  used  for  a 
two-space  display 

SRTFLG 

7 

RNKCRD 

the  index  in  the  Cl  file  array 
for  the  sort  sort  flag 

SUBPGM 

1 

INSGLBL 

signifies  to  INSPGM  that  the 
calling  routine  was  c  a 
subprogram 

SV 

8 

FCCS 

saved  vector  file  code  (FCC) 

SVHNE 

2 

LENGTH 

the  length  (in  real  elements) 
of  the  saved  vector  file 

SVLENE 

59 

LENGTH 

the  length  (in  real  elements) 
of  a  logical  entry  of  the  saved 
vector  file 

TABSIZ 

100 

TIFILE 

the  maximum  size  of  a  TI  entry 
table 

TIFILE 

1 

FTYPE 

the  tree  information  file  type 
indicator 

TIHSIZ 

105 

TIFILE 

the  size  (in  elements)  of  the 
TI  file  header 

TL 

2 

FCCS 

tree  list  file  code  (FCC) 

TLHNE 

2 

LENGTH 

the  length  (in  real  elements) 
of  the  tree  list  file  header 

TLLENE 

12 

LENGTH 

the  length  (in  real  elements) 
of  a  logical  entry  of  the  tree 
list  file 

I 


CLPARS  Parameter  Limits  --  H 
Alphabetized 


Parameter  Value  Location  Description 


TRELEN 

8 

STANDARD 

maximum  length  of  a  treename 

TVFILE 

2 

FTYPE 

the  tree  vector  file 

ind icator 

type 

TVHENE 

1 1 

TVFILE 

the  tree  vector  file's 
entry  size 

header 

TWOS PC 

2 

DISPLAY 

two-space  indicator 

USAGE 

2 

CALUN 

usage  portion  of  ’Luntbl 

t 

USEE 

1 

CALUN 

value  to  indicate  that  a 
is  used 

•LUN  ' 

VP 

1 1 

TIFILE 

the  code  for  accessing  the 
vector  pointer  to  the  vectors 
of  a  node  in  the  TV  file 

VRMLEN 

30 

INSGLBL 

length  of  a  Hollerith 
representing  a  variable 

string 

name 

WC 

5 

SCREEN 

index  to  the  number  of 
units  in  character  width 

display 

WC 

3 

SCREEN 

index  to  the  number  of 
units  in  display  width 

display 

WID 

0 

DISPLAY 

dummy  parameter  for 

routines 

btmap 

WRITE 

1 

STANDARD 

write  indicator  to 

routines 

'OPEN  ' 

WS 

1 

SCREEN 

index  to  the  number  of 
units  in  screen  width 

display 

ZOOM 


1 


DISPLAY 


the  flag  indicating 
zooming  is  in  effect 


that 


CLPARS  Parameter  Limits  --  H 
According  to  File  Location 


Parameter 

Value 

Location 

BHFSIZ 

2 

BITMAP 

SBTMAP 

21 

BITMAP 

FREE 

0 

CALUN 

LUNFTR 

1 

CALUN 

MAXLUN 

15 

CALUN 

USAGE 

2 

CALUN 

USED 

1 

CALUN 

ALPHA 

1 

CHARTYPE 

ALPHNK 

2 

CHARTYPE 

A NYC HR 

3 

CHARTYPE 

DIGIT 

2 

CHARTYPE 

LETTER 

1 

CHARTYPE 

OTHER 

11 

CHARTYPE 

PASCII 

3 

CHARTYPE 

ACCESS 

0 

DISPLAY 

ANGLE 

0 

DISPLAY 

CLUSTR 

1 

DISPLAY 

CCNMAT 

4 

DISPLAY 

DINITM 

17 

DISPLAY 

DVNITM 

4 

DISPLAY 

HGT 

0 

DISPLAY 

IGNORE 

-1 

DISPLAY 

INDI 

0 

DISPLAY 

MACRO 

5 

DISPLAY 

MENVEC 

-1 

DISPLAY 

MICRO 

6 

DISPLAY 

NOTSET 

0 

DISPLAY 

NOZCCM 

0 

DISPLAY 

OFF 

0 

DISPLAY 

ON 

1 

DISFLAY 

ONESPC 

1 

DISPLAY 

PVNITM 

6 

DISPLAY 

RECTAN 

0 

DISPLAY 

RNKORD 

3 

DISPLAY 

S1NITM 

4 

DISPLAY 

SCATTR 

2 

DISPLAY 

SQUARE 

1 

DISPLAY 

TWCSPC 

2 

DISPLAY 

WID 

0 

DISPLAY 

ZOOM 

1 

DISPLAY 

Parameter 

Value 

Location 

MAXSEG 

10 

DSCRMTHR 

BUFSIZ 

128 

FACT 

FLAKSZ 

13 

FACT 

MAXEUF 

1 

FACT 

MAXFIL 

15 

FACT 

CM 

1 

FCDS 

D I 

4 

FCDS 

DV 

5 

FCDS 

HS 

10 

FCDS 

LL 

3 

FCDS 

PV 

6 

FCDS 

SI 

7 

FCDS 

SM 

9 

FCDS 

SV 

8 

FCDS 

TL 

2 

FCDS 

FIXED 

5 

FTYPE 

LIFILE 

3 

FTYPE 

LVFILE 

4 

FTYPE 

TIFILE 

1 

FTYPE 

TVFILE 

2 

FTYPE 

MAXSEG 

1C 

GP2BLK 

HSTBSZ 

503 

HISTRY 

INITHR 

5 

HISTRY 

MAXHSP 

20 

HISTRY 

MAXNAM 

9 

HISTRY 

MAIN 

0 

INSGLBL 

SUBPGM 

1 

INSGLBL 

VRNLEN 

30 

INSGLBL 

LEVEL1 

0 

INSTRU 

CMHNE 

97 

LENGTH 

CMLENE 

0 

LENGTH 

DIHNE 

1 

LENGTH 

DILENE 

1 

LENGTH 

DVHNE 

1 

LENGTH 

257 


CLPARS  Parameter  Limits  --  H 
According  to  File  Location 


Parameter 

Value 

Location 

Parameter 

Value 

DVLENE 

1 

LENGTH 

NCDENL 

2 

HSHNE 

1 

LENGTH 

NODLVL 

1 

HSLENE 

5 

LENGTH 

PRNTND 

3 

LLHNE 

2 

LENGTH 

SIELND 

5 

LLLENE 

25 

LENGTH 

PVHNE 

18 

LENGTH 

CLSDBN 

4 

PVLENE 

1 

LENGTH 

GRPLCG 

tL 

S1HNE 

1 

LENGTH 

INCPLT 

0 

S1LENE 

1 

LENGTH 

LOWEST 

6 

SMHNE 

1 14 

LENGTH 

NMVLOG 

3 

SMLENE 

51 

LENGTH 

NRSTNB 

5 

SVHNE 

2 

LENGTH 

PAIRWS 

1 

SVLENE 

59 

LENGTH 

TLHNE 

2 

LENGTH 

LVHENE 

3 

TLLENE 

12 

LENGTH 

LVLMIN 

12 

LIHENE 

272 

LIFILE 

HDRLEN 

3 

LILENE 

22 

LIFILE 

MAXO  PT 

15 

MAXPGM 

106 

ALIFLG 

7 

LIHDR 

MENUMX 

20 

DDSDIM 

1 

LIHDR 

OFNLEN 

10 

DDSNLN 

2 

LIHDR 

OPTLE 

9 

LNCRNT 

6 

LIHDR 

PGMLEN 

10 

LVNELM 

8 

LIHDR 

NINCLN 

9 

LIHDR 

MESVEC 

1 

NNUSED 

5 

LIHDR 

NXTAVN 

3 

LIHDR 

CLPBMS 

5 

N XT END 

4 

LIHDR 

CLSEMS 

4 

DC 

1 

EXMLIM 

150 

LIMITS 

DSPCHR 

8 

MAXBDY 

2 

LIMITS 

MECLPR 

3 

MAXBIN 

50 

LIMITS 

MBYCLS 

2 

MAXBPT 

6 

LIMITS 

N  DIMEN 

3 

MAXCLS 

50 

LIMITS 

NUMCLS 

4 

MAXDIM 

50 

LIMITS 

OPTNUM 

2 

MAXVEC 

32767 

LIMITS 

OVRALL 

1 

NDISP 

6 

LIMITS 

RNKOPT 

5 

RNKPRM 

6 

FKIDND 

4 

LISTRC 

SRTFLG 

7 

LSTRSZ 

7 

LISTRC 

LVLOGK 

6 

LISTRC 

LVRJCT 

7 

LISTRC 

258 


Location 


LISTRC 

LISTRC 

LISTRC 

LISTRC 

LCGTYPE 

LCGTYPE 

LCGTYPE 

LCGTYPE 

LCGTYPE 

LCGTYPE 

LCGTYPE 

LVFILE 

LVFILE 

OPTION 

OPTION 

OPTION 

OPTION 

GPTION 

OPTION 

OPTION 

PVFILE 

RNKORD 

RNKORD 

RNKORD 

RNKORD 

RNKORD 

RNKORD 

RNKORD 

RNKORD 

RNKORD 

RNKORD 

RNKORD 

RNKORD 

RNKORD 


CLPARS  Parameter  Limits  --  H 
According  to  File  Location 


Parameter 

Value 

Location 

Parameter 

Value 

A 

7 

SCREEN 

CUIT 

-1 

E 

8 

SCREEN 

READ 

0 

C 

S 

SCREEN 

SAVE 

0 

D 

10 

SCREEN 

TRELEN 

8 

DS 

19 

SCREEN 

WRITE 

1 

E 

15 

SCREEN 

F 

16 

SCREEN 

BFET 

12 

G 

17 

SCREEN 

CAPSI2 

12 

KC 

6 

SCREEN 

ENMEAN 

17 

HD 

4 

SCREEN 

FCP 

7 

HSN 

2 

SCREEN 

FLNP 

8 

LCH 

13 

SCREEN 

FRELST 

13 

MRW 

11 

SCREEN 

LNBP 

10 

NC 

18 

SCREEN 

LNLP 

9 

HCL 

12 

SCREEN 

NL 

4 

NOSCRN 

19 

SCREEN 

NLNODE 

2 

SC2NUM 

13 

SCREEN 

NO KIDS 

3 

WC 

5 

SCREEN 

NCVECS 

1 

WD 

3 

SCREEN 

PP 

C, 

WS 

1 

SCREEN 

SP 

6 

TABSIZ 

IOC 

MAXNiTR 

10 

SMFILE 

TIHSIZ 

105 

VP 

1 1 

APPEND 

2 

STANDARD 

CMCLEN 

10 

STANDARD 

TVHEIIE 

1  1 

DATA 

1 

STANDARD 

DELETE 

1 

STANDARD 

EOF 

-1 

STANDARD 

EOS 

0 

STANDARD 

ERROR 

-1 

STANDARD 

FNMLEN 

34 

STANDARD 

HEADER 

0 

STANDARD 

HELP 

-2 

STANDARD 

LOGIC 

2 

STANDARD 

MAXLIN 

133 

STANDARD 

NEW 

1 

STANDARD 

NFIXFL 

10 

STANDARD 

NODLEN 

4 

STANDARD 

OLD 

0 

STANDARD 

Location 


STANDARC 

STANDARD 

STANDARD 

STANDARD 

STANDARD 

TIFILE 

TIFILE 

TIFILE 

TIFILE 

TIFILE 

TIFILE 

TIFILE 

TIFILE 

TIFILE 

TIFILE 

TIFILE 

TIFILE 

TIFILE 

TIFILE 

TIFILE 

TIFILE 

TIFILE 

TVFILE 


APPENDIX  J 


File  type  naming  conventions 
of  GLPARS  files 


This  text  is  dedicated  to  the  cause  of  'keeping  straight'  all 
the  different  file  name  types  (or  file  extension  names)  found 
within  the  RSX-11M  version  of  portable  CLPARS.  As  is  known  by 
those  people  who  are  familiar  with  EEC's  RSX,  a  file  specification 
looks  like: 

<f ilename> .<type>;<version  number> 

where  <filename>  is  a  0-9  character  string  of  letters  and/cr 

digits , 

<type>  is  a  0-3  character  string  of  letters  and/or 

digits,  and 

<version  number>  is  an  octal  number,  used  in  uniquely 

identifying  files  with  the  same 
<filename>  and  <type>. 

This  text  will  only  deal  with  the  <type>  portion  of  the  RSX 
filename . 

First,  you  must  be  introduced  to  the  abbreviations  used  here. 
The  following  mneumonics  refer  to  specific  software  tools  used  in 
constructing  CLPARS. 


File  type  (extension)  naming  convensicns  —  J 


AFT 

- 

PAR'S 

FORTRAN  preprocessor 

LSR 

- 

DEC  Standard  Runoff  (VMS  text  formatter) 

F4P 

- 

EEC's 

FCRTRAN  IV  Plus  compiler 

INC 

- 

PAR'S 

•include'  utility  program 

LER 

- 

DEC'S 

object  module  librarian 

MAC 

- 

EEC's 

macro  assembler 

ML'N 

- 

another  name  for  TEC 

PIP 

- 

DEC'S 

file  transferring  program 

RNO 

- 

(runoff)  a  text  formatter 

TEC 

- 

TECo 

(text  editor  and  corrector) 

TKB 

DEC'S 

task  builder  (linker) 

We  can  now  proceed  to  the  file  type  (extension)  naming 
conventions  used  in  the  portable  OLPARS  project.  Note  that  the 
period  (.)  portion  of  the  file  specification  will  preceed  all  the 
following  <type>  names  (this  is  to  remind  you  that  the  3  characters 
represent  file  extension  names). 

.AFT  -  OLPARS  programs  to  be  'AFT*  processed 
.ALG  -  textual  ali>rithms  to  be  processed  by  'RNO' 

.ASM  -  OLPARS  assembly  files  that  must  be  'INClude'  processed 

•BLD  -  task  build  (linker)  command  files 

.CMC  -  RSX-11M  processor  command  files 

.DCL  -  AFT  or  assembly  declaration  files  (to  be  'INCluded') 

.DOC  -  text  files  already  processed  by  the  'RNO'  utility 

.FIG  -  OLPARS  figure  documents  (post  ’RNO'  processed,  pre  ’INC*) 

.FTN  -  FORTRAN  files  to  be  processed  by  *F4P' 


File  type  (extension)  naming  convensions  --  J 


•HER  -  documentation  headers  for  CLPARS  programs 
( to  be  ' INCluded ' ) 

.INC  -  'INClude'  processor  input  files 

.HAN  -  manuals  after  ’RNO'  processing 

.MAC  -  assembly  files  to  be  processed  by  'MAC' 

.CBJ  -  program  object  modules  used  by  task  builder  and  librarian 

•ODL  -  task  build  (linker)  overlay  description  files 

/ 

.CLP  -  OLPARS  binary  information  files 

.PAM  -  CLPARS  programmer  aide  documents  before  'RNO'  processing 
.PIC  -  pictures  (figures)  to  be  processed  by  'RNO* 

. PRM  -  CLPARS  programmer's  reference  manual  before  'RNC' 
processing 

•PTH  -  path  name  files  used  by  the  'INClude'  processor 
.RNO  -  text  files  to  be  processed  by  the  'RNC  utility 
.SPC  -  OLPARS  program  specification  documents  (to  be  'RNC' 
processed ) 

.SRM  -  OLPARS  software  reference  manual  before  'RNO'  processing 
.SRC  -  OLPARS  'AFT'  source  files  that  must  be  ’INClude'  processed 
•TEC  -  TECo  command  files 

.TPL  -  template  files  used  in  generating  documentation  or  command 
files 

.TSK  -  task  images  of  executable  programs 
.TXT  -  Miscellaneous  text  files 

.USM  -  OLPARS  user  manual  documents  before  'RNC'  processing 
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File  type  (extension)  naming  conversions  --  J 
File  Types  and  their  Process  Relationships 

About  Files  and  Processes 

The  chart  on  the  following  page  shows  the  relationships 

between  the  previously  mentioned  CLPARS  file  types  anc  processes. 

In  the  chart,  processes  are  represented  with  boxes,  file  types  are 
denoted  with  an  initial  period  (.).  The  6  symbol  surrounding 

processes  and  file  types  indicates  which  operations  are  performed 

by  the  RSX-1 1M  command  file  processor.  Lines  intersecting  process 
boxes  show  that  the  file  at  the  other  end  of  the  line  is  used  as 
input  to  the  process  ("Arrowed"  lines  are  used,  aj.so). 


CMC 


:  AT.  (€)  ! 


I  I 

t  I 


eeeeeeeeeeeieeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeGeeMGeeee 


—  .HER  <-- 


--  .  LCL 


HUN 


<-  .  CCC  < — 


RNC 


<- 


COMMENT. TEC 


SPC 
,  ALG 


--  .FIG  <--  !  MUN 


<-  .LGC  < — 


RNO 


<-  .PIC 


,  SRC 


-> 


INC 

I 

.  PTH 
» 

.  — —  1  — - 

INC 


-->  .AFT  ->  !  AFT  !  -->  ,FTN  -> 


F4P 


-->  .MAC  ->  | 


.ASM 


MAC  !  -->  . OE J  < - 

-  /  \ 

/  \ 

(main  programs)  /  \  (subrtns.) 

/  \ 

- /.  -\ - 


.TSK  <--  |  TKB 


LBR 


Relationships  between 
files  and  processes 


.BLD  . CLB  <- 
.ODL 


@e@eeee@@@§e@@§ee@0@@@e@e§@§e§@@§§@@§@§§@@@e€@e@§@e@e€e§e@§§@@§e@§ 


INC 


! — >  . PRM  ->!  PIP  .RNO  ->|  DSR 


!-->  .MAN 


-  .USM 

-  .PAM 

-  .  SRM 


@@€@@@@§@0@§§§@§<?§§@e§§@@§eeee§§§e§@ee§@§eee§§§e§§§ee§§§§§e@eeeeeee§ 


Miscellaneous  <--  |  .TSK  !  <--  .CLP 

text  files  -  .TXT  (some,  not  all) 
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AFFENDIX  K 


Miscellaneous  Text  Files  Created  by 
GLPARS  Commands 


The  following 

list  contains  the 

names 

of  the  various 

text 

files  created  by 

CLPARS  commands 

along 

with  the  name  of 

the 

creating  ccmmmand 

( in  parenthesis)  . 

Note , 

these  files  have 

no 

<type>  name. 


CLASIFY 1 

list  of  logic  nodes  and  number  of  vectors 
assigned  to  each  node. 

( LGGEVAL) 

CLASIFY2 

— 

list  of  vector  identifiers  and  logic  nodes 
to  which  they  were  assigned  . 

( LCGEVAL) 

CCNMAT 

- 

confusion  matrix  listing. 

(LOGEVAL,  KM EVA L,  PWEVAL) 

EIGEN 

- 

eigenvalue  listing. 

(L1EIGV,  L2EIGV,  REPRGJECT,  S1EIGV, 

S2EIGV) 

LOGCUMP 

- 

logic  tree  dump. 

( PRTLOG ) 

MISCLASS 

- 

vector  misclassif ication  listing. 

( CREATLCG ,  LCGEVAL,  NMEVAL,  PWEVAL) 

SAVMTR 

- 

a  saved  matrix  listing. 

(MATRIX) 

TREE  DUMP 

- 

data  tree  dump. 

( PRTCS ) 

VECIDS 

- 

new-old  vector  identifier  relationship 
listing . 

(MAKETREE) 
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"fixed"  files  .  215 

"variable"  files  .  22C 

(graphics  pkg  . )  ERASE .  159 

(graphics  pkg.)  LINSEG  .  159 

(graphics  pkg.)  MARK .  159 

(graphics  pkg.)  MOVE .  1 5 S 

(graphics  pkg.)  RCTNGL  .  159 

(graphics  pkg.)  TEXT  .  .....  .  158 

AESTRACT  FILES  AND  INPUT/OUTPUT  .  4 

ADDITIONAL  CONSIDERATIONS  .  35 

ASPECTS  OF  PORTABILITY  .  5 

BATCH  PROCESSING  IN  OLPARS .  168 

BOOLEAN  STATEMENT  INTERPRETER  .  167 

COMMAND  INPUT  PROCESSOR  (CIP)  .  3,  7,  177 

COMMAND  STRUCTURE  .  A 

CONFUSION  MATRICES  .  133 

CREAFX . 219 

CREATING  NEW  TREES  FROM  OLD  TREES . 42 

CURRENT  MIN-MAX  COORDINATES  .  115 

DATA  TREE  INPUT/OUTPUT .  163 

DESIGN  OVERVIEW  .  2 

DISPLAY  FILES  USED  IN  MEASUREMENT  EVALUATION  .  126 

ESCAPE  CHARACTERS  .  141 

EXPANDABILITY  .  172 

EXPANDING  OLPARS  UNDER  RSX-11M  .  197 

FGET . 22 

FILE  ACCESS  AND  CONTROL  TABLE  (FACT)  .  17-18,  22,  215 

FILE  CODE  TABLE  (FCT)  .  16,  18 

FILE  CODES  FOR  "FIXED"  FILES  (FCDs)  .  17 

FILE  CODES  FOR  "VARIABLE"  FILES  (FCDs)  .  17 

FILE  DESCRIPTORS  .  17-18,  22 

FILE  SYSTEM  ROUTINES  AND  USAGE . 13 

FILENAMES  VERSUS  TREE  NAMES  .  176 

FILGET .  160 

FILPUT .  161 

FORTRAN  CODE  GENERATION  .  165 

FPUT . 22 

GEN  (generate  CLPARS  user's  fixed  files)  .  231 

GRAPHICS  INPUT  UTILITY  PROGRAM  (GIN)  .  .  .  157 

GRAPHICS  OUTPUT  UTILITIES  .  158 


HELP  FUNCTION  ON  RSX-1 1M 


199 
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INSHSP  (Instrumentation  History  file  Patch  routine)  .  234 

Instrumentation  Package  .  203 

Instrumentation  Fackage  Programs  .  212 

Level  I  File  Access  Routines . 22 

Level  I  Manipulation  Routines .  18 

Level  II  program  naming  conventions  .  24 

Level  II  Routines . 24 

LOGIN  -  LOGOUT .  174 

MAKGPT  (make  the  CLPARS  option  file)  .  235 

Miscellaneous  Text  Files  in  CLPARS . .  265 

NOTES  GN  TERMINAL  I/C .  156,  163 

NOTES  ON  TEXT  FILE  I/O .  163 

OCLOSE .  13,  20 

OCREAT .  13,  18,  219 

ODELET . 20 

ODTDMP  (OLPARS  Data  Tree  Dump) . 236 

OLPARS  FILE  "FREE"  LISTS  .  44 

OLPARS  I/O  notes  (for  RSX-11M) . 219 

OLPARS  TRANSPORTATION  CONSIDERATIONS  .  5 

OLTCMP  (OLPARS  Data  Tree  Dump) . 239 

OMOVE .  13,  20 

ONE-SPACE  DISPLAYS  (MICRO  AND  MACRO)  .  116 

OOPEN .  13,  18,  20,  219 

OPENFX . 219 

ORENAM .  13,  20 

ORIGINAL  MIN-MAX  COORDINATES  .  115 

PARAMETER  LIMITS  .  242 

PORTABILITY .  1,  3,  5 

PRINTER  LISTINGS  .  161 

PROGRAMMER  AIDES  .  230 

RSX-11M  Block  I/O  for  CLPARS .  220,  224 

RSX-11M  File  I/O  Communication  Paths  .  222 

RSX-11M  file  naming  conventions  .  260 

RSX-1 1M  file  types  and  their  process  relationships  .  .  263 

RSX-1 1M  I/O  notes . 219 

RSX-1 1M  logical  unit  allocation  .  222 

RSX-1 1M  Record  I/C  for  OLPARS .  221,  226 

RSX-1 1M  System  Dependent  files  .  182 

RSX-1 1M  task  building  example  (non-overlay)  .  229 

RSX-1 1M  task  building  notes  for  OLPARS  .  227 

RSX-1 1M  user  files . 219 

SCALING  IN  TWO-SPACE  DISPLAYS  ....  .  115 

Screen  Parameters  for  One  Space  Displays  .  122 


TERMINAL  CHARACTER  INPUT/OUTPUT 
TERMINAL  GRAPHICS  INPUT/OUTPUT 
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TEXT  FILE  INFUT/OUTPUT .  160 

THE  COMMUNICATIONS  (CM)  FILE . 27 

THE  DISPLAY  INFORMATION  (DI)  FILE . 96 

THE  DISPLAY  VALUE  (DV)  FILE .  102 

THE  LOGIC  INFORMATION  (LI)  FILE . 52 

T Li  LOGIC  LIST  (LL)  FILE . £6 

THE  LOGIC  VALUE  (LV)  FILE . '.  .  60 

THE  PROJECTION  VECTOR  (PV)  FILE .  105 

THE  SAVED  TRANSFORMATION  MATRIX  (SM)  FILE . 90 

THE  SAVED  VECTORS  (SV)  FILE . £6 

THE  TREE  INFORMATION  (TI)  FILE(S) . 29 

THE  TREE  LIST  (TL)  FILE  . . 50 

THE  TREE  VECTOR  (TV)  FILE . 47 

TREE  INFORMATION  (TI)  FILE  EXAMPLE . 40 

TRMCET .  149 

TRMPUT .  143 

TWC-SPACE  DISPLAYS  (SCATTER  AND  CLUSTER)  .  95 

user  data  and  logic  files . 220 

USER  FILE  DEFINITIONS .  10 

User  files  on  RSX-11M . 219 


